Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp3108573rwp; Fri, 14 Jul 2023 17:55:27 -0700 (PDT) X-Google-Smtp-Source: APBJJlGAiMLmUE0KabYa+O3iK62N/y3DDEMFqMBqM6yzk/po9W6H9WBxNpXCXtObnHPxzmkF0Crf X-Received: by 2002:a17:906:10ca:b0:994:3395:942f with SMTP id v10-20020a17090610ca00b009943395942fmr5296635ejv.17.1689382527131; Fri, 14 Jul 2023 17:55:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689382527; cv=none; d=google.com; s=arc-20160816; b=SzY7N4uT/u3/yhwvNDc/M8N4EEzi+IE2NzZtcfZrJaAcvYGMlSeQ2ZOWNboNAAD5Cj PFiWrleQzmzwg9xlOy6ljsDPVGXCLtbUQSedcnA663s2+2LcLmNokoHZj6AVkT1KpyZO 6S/V6+ESQ9CaAHi6mQfqjKYpaByzFGxPUG1vZyFx0l0V7ZNzHhzFCJwieUQCAAxnesDj EOPxPzrv1z8d2I3QDuzikBsr/jdYFNk5hUPZgD1jlnjlrkbw37yHD6AN6QC+aggaLZXp rvZB6OHAmXHwky29Ljjj2rHQVXMsN7NVPDf3rKChxfyrcAUEvRGYOjzLcQGMtdlqzzi2 PCsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=DXSb2wBFM1YqX3e0K095JGVqbv6jEC0ptWgkO+jVxEk=; fh=cg08KfybVIjOPEOl0Hv/+IYUHFKAuZqpofM7kPrFHwY=; b=i7xuoi6pawMoxCSHMoWLIgvrwXGWWcMU2q1jvCT6V1ohtB4rVfNydD5isi80AuTv4g OOptUT9acw7CL/PkjkIn8jSkiOgz7KWtO/UBiSrq8wBanCXuO9DyAyhHcs7vmOdiScSy MaVo7lBD8pp3kYjBwO3X3V7Ni4Z86CNTmBKsLeQ/ULixdSi8pObIaQNbDYknP3yBD8mF ABPwoZuZ8girckwy7b2+pwTdHE877i9kaG9IYf9pYAJ+AhbhPgxhSaYfphDAJkcHT0JG LJjOLyIs6G9hxlcq1eMNOrlEbX4nh71U3TatAx2mv4RtPI12Bt3NmH7oHhOrBIv4dd/7 gMmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=QF+3v9gg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y18-20020a170906559200b00992f30b2983si9043797ejp.849.2023.07.14.17.55.03; Fri, 14 Jul 2023 17:55:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=QF+3v9gg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229796AbjGNX3E (ORCPT + 99 others); Fri, 14 Jul 2023 19:29:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46658 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229530AbjGNX3D (ORCPT ); Fri, 14 Jul 2023 19:29:03 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D27FD3A87 for ; Fri, 14 Jul 2023 16:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689377342; x=1720913342; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=uiYTcJPJmh4W/QVY1yRB8BdNSrQ492BteeJa949PR+Y=; b=QF+3v9ggLs1Km8KV5GGMnOXWHuBS4YoS5DFbR5U4u9B1NB5N58+ig5ay d5bu0HMFugFT6FXp5LJe86SoGnRPxAQSMWG2w58xyWySGsdLAB3vvnSUO h6t3M/Vu87dQkWtW/TIksL2DA9nPZ/uWVoKWgma2kscltZh+oV+o6Tcrg B9KgfaYa878PtKSY7JkxstksiKiPZoxNDyMH3Ww1A15Sn9yjXX/1Dkzc4 OteWTpemP3Z1oU23uKAIKLc7D8Nu3CqB5LFxNhLBNRn0cfrIDh2zG5RtY jYhInN945Av/TDtqPKyhzYtfWS9moNYg82Kqj/lT7naSTlb8s1q+eI69w A==; X-IronPort-AV: E=McAfee;i="6600,9927,10771"; a="431779224" X-IronPort-AV: E=Sophos;i="6.01,206,1684825200"; d="scan'208";a="431779224" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2023 16:29:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10771"; a="1053240913" X-IronPort-AV: E=Sophos;i="6.01,206,1684825200"; d="scan'208";a="1053240913" Received: from bmuller-mobl.amr.corp.intel.com (HELO [10.209.37.94]) ([10.209.37.94]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2023 16:29:01 -0700 Message-ID: <9de4ecabf658458f3f45f6970707a0b1458c6394.camel@linux.intel.com> Subject: Re: [Patch v3 1/6] sched/fair: Determine active load balance for SMT sched groups From: Tim Chen To: Tobias Huschle Cc: Peter Zijlstra , Juri Lelli , Vincent Guittot , Ricardo Neri , "Ravi V . Shankar" , Ben Segall , Daniel Bristot de Oliveira , Dietmar Eggemann , Len Brown , Mel Gorman , "Rafael J . Wysocki" , Srinivas Pandruvada , Steven Rostedt , Valentin Schneider , Ionela Voinescu , x86@kernel.org, linux-kernel@vger.kernel.org, Shrikanth Hegde , Srikar Dronamraju , naveen.n.rao@linux.vnet.ibm.com, Yicong Yang , Barry Song , Chen Yu , Hillf Danton Date: Fri, 14 Jul 2023 16:29:00 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) MIME-Version: 1.0 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > >=20 > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 87317634fab2..f636d6c09dc6 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -8279,6 +8279,11 @@ enum group_type { > > * more powerful CPU. > > */ > > group_misfit_task, > > + /* > > + * Balance SMT group that's fully busy. Can benefit from migration > > + * a task on SMT with busy sibling to another CPU on idle core. > > + */ > > + group_smt_balance, >=20 > Would it make sense to move smt_balance?, s.t. we get: >=20 > group_has_spare < group_smt_balance < group_fully_busy >=20 > Conceptually I would be more intuitive to me like this as the > smt_balance groups are more busy than has_spare ones, but less busy > then fully_busy ones. >=20 > From a functional perspective I could also see some impact when > update_sd_pick_busiest compares the group types. In that case we > would remove tasks from fully busy groups before moving them > from smt_balance groups. Not sure which way would be to prefer > to increase overall throughput. >=20 > Since smt_balance is only selected if the group has SMT, this > should still not pull the last task off of a non-SMT CPU. >=20 >=20 I think you have similar concerns as Shrikanth on this patch. Can you see if my fix to update_sd_pick_busiest() in my reply to Shrikanth addresses what you have in mind. Tim