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;
Message-ID: <f7dc49b5fb80b25ad1f3968a623f993da29c0526.camel@linux.intel.com>
Subject: Re: [Patch v2 1/6] sched/fair: Determine active load balance for
 SMT sched groups
From:   Tim Chen <tim.c.chen@linux.intel.com>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Juri Lelli <juri.lelli@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Ricardo Neri <ricardo.neri@intel.com>,
        "Ravi V . Shankar" <ravi.v.shankar@intel.com>,
        Ben Segall <bsegall@google.com>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Len Brown <len.brown@intel.com>, Mel Gorman <mgorman@suse.de>,
        "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
        Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Valentin Schneider <vschneid@redhat.com>,
        Ionela Voinescu <ionela.voinescu@arm.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org,
        Shrikanth Hegde <sshegde@linux.vnet.ibm.com>,
        Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
        naveen.n.rao@linux.vnet.ibm.com,
        Yicong Yang <yangyicong@hisilicon.com>,
        Barry Song <v-songbaohua@oppo.com>,
        Chen Yu <yu.c.chen@intel.com>, Hillf Danton <hdanton@sina.com>
Date:   Mon, 12 Jun 2023 13:12:10 -0700
In-Reply-To: <20230612111359.GI4253@hirez.programming.kicks-ass.net>
References: <cover.1686263351.git.tim.c.chen@linux.intel.com>
         <253f5272200d3cec3f24427262bb4e95244f681c.1686263351.git.tim.c.chen@linux.intel.com>
         <20230612111359.GI4253@hirez.programming.kicks-ass.net>
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
Precedence: bulk

On Mon, 2023-06-12 at 13:13 +0200, Peter Zijlstra wrote:
>=20
>=20
>=20
> > @@ -9537,6 +9581,18 @@ static bool update_sd_pick_busiest(struct lb_env=
 *env,
> >  		break;
> > =20
> >  	case group_has_spare:
> > +		/*
> > +		 * Do not pick sg with SMT CPUs over sg with pure CPUs,
> > +		 * as we do not want to pull task off half empty SMT core
> > +		 * and make the core idle.
> > +		 */
> > +		if (smt_vs_nonsmt_groups(sds->busiest, sg)) {
> > +			if (sg->flags & SD_SHARE_CPUCAPACITY)
> > +				return false;
> > +			else
> > +				return true;
> > +		}
>=20
> However, here I'm not at all sure. Consider SMT-4 with 2 active CPUs, we
> still very much would like to pull one task off if we have an idle core
> somewhere, no?
>=20

How about making this modification to take care of SMT-4 case?

Tim

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 33246dce10db..e2261c24e536 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -9642,11 +9642,11 @@ static bool update_sd_pick_busiest(struct lb_env *e=
nv,
        case group_has_spare:
                /*
                 * Do not pick sg with SMT CPUs over sg with pure CPUs,
-                * as we do not want to pull task off half empty SMT core
+                * as we do not want to pull task off SMT core with one tas=
k
                 * and make the core idle.
                 */
                if (smt_vs_nonsmt_groups(sds->busiest, sg)) {
-                       if (sg->flags & SD_SHARE_CPUCAPACITY)
+                       if (sg->flags & SD_SHARE_CPUCAPACITY && sgs->sum_h_=
nr_running <=3D 1)
                                return false;
                        else
                                return true;

	=09