All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Righi <arighi@nvidia.com>
To: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	Christian Loehle <christian.loehle@arm.com>,
	Koba Ko <kobak@nvidia.com>,
	Felix Abecassis <fabecassis@nvidia.com>,
	Balbir Singh <balbirs@nvidia.com>,
	Shrikanth Hegde <sshegde@linux.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection
Date: Tue, 21 Apr 2026 14:31:37 +0200	[thread overview]
Message-ID: <aeduKWloTY86JYgy@gpd4> (raw)
In-Reply-To: <3cc4d887-f44d-4fe8-a57a-73f595647eab@amd.com>

On Tue, Apr 21, 2026 at 04:52:46PM +0530, K Prateek Nayak wrote:
> Hello Andrea,
> 
> On 4/21/2026 3:05 PM, Andrea Righi wrote:
> > Actually... while preparing the series I realized that in select_idle_capacity()
> > we may end up clearing the has_idle_cores hint even when the failure is due to
> > affinity constraints (no fit CPU in the allowed cpumask), not only when no fully
> > idle core is found in the system and this can lead to false has_idle_cores
> > hints.
> 
> This is also the case with select_idle_cpu() but any core turning
> idle will again reset the indicator so it should be fine for most
> part where there is a lot of blocking + wakeup.

You're right, select_idle_cpu() is also iterating on the allowed CPUs. So,
nevermind, we definitely want to use the has_idle_cores hint.

> 
> > 
> > At this point I'm wondering if it's better to just ignore the has_idle_cores
> > hint completely in the smt+asym-cpu-capacity scenario (which would also simplify
> > the exotic topology cases).
> > 
> > I did some quick tests with this on Vera and I'm getting pretty much the same
> > performance results. Opinions? Am I missing something?
> 
> I don't think so. Generally it is counterproductive to search a lot
> in a busy system but I guess just making the path SMT aware give a
> much better result compared to the baseline that it doesn't matter.
> 
> Can I trouble you to test the SIS_UTIL bailout with your series +
> the topology changes:
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 78f2d2c4e24f..1356bbdbccd4 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -7990,6 +7990,7 @@ select_idle_capacity(struct task_struct *p, struct sched_domain *sd, int target)
>  	int fits, best_fits = 0;
>  	int cpu, best_cpu = -1;
>  	struct cpumask *cpus;
> +	int nr = INT_MAX;
>  
>  	cpus = this_cpu_cpumask_var_ptr(select_rq_mask);
>  	cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
> @@ -7998,10 +7999,30 @@ select_idle_capacity(struct task_struct *p, struct sched_domain *sd, int target)
>  	util_min = uclamp_eff_value(p, UCLAMP_MIN);
>  	util_max = uclamp_eff_value(p, UCLAMP_MAX);
>  
> +	if (sched_feat(SIS_UTIL) && sd->shared) {
> +		/*
> +		 * Increment because !--nr is the condition to stop scan.
> +		 *
> +		 * Since "sd" is "sd_llc" for target CPU dereferenced in the
> +		 * caller, it is safe to directly dereference "sd->shared".
> +		 * Topology bits always ensure it assigned for "sd_llc" abd it
> +		 * cannot disappear as long as we have a RCU protected
> +		 * reference to one the associated "sd" here.
> +		 */
> +		nr = READ_ONCE(sd->shared->nr_idle_scan) + 1;
> +		/* overloaded LLC is unlikely to have idle cpu/core */
> +		if (nr == 1)
> +			return -1;
> +	}
> +
>  	for_each_cpu_wrap(cpu, cpus, target) {
>  		bool preferred_core = !prefers_idle_core || is_core_idle(cpu);
>  		unsigned long cpu_cap = capacity_of(cpu);
>  
> +		/* We have found a good enough target. Just use it. */
> +		if (--nr <= 0 && best_fits == -4)
> +			return best_cpu;
> +
>  		if (!choose_idle_cpu(cpu, p))
>  			continue;
>  
> ---
> 
> You can also try "best_fits <= -3" in that last bailout condition and
> see if that help.

Sure, will test in a bit!

Thanks,
-Andrea

  reply	other threads:[~2026-04-21 12:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-03  5:31 [PATCH v2 0/2] sched/fair: SMT-aware asymmetric CPU capacity Andrea Righi
2026-04-03  5:31 ` [PATCH 1/2] sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection Andrea Righi
2026-04-07 11:21   ` Dietmar Eggemann
2026-04-18  8:24     ` Andrea Righi
2026-04-20  5:49       ` K Prateek Nayak
2026-04-20  8:36         ` Andrea Righi
2026-04-20  9:39           ` K Prateek Nayak
2026-04-20 21:42             ` Andrea Righi
2026-04-21  9:01               ` Andrea Righi
2026-04-21  9:35                 ` Andrea Righi
2026-04-21 11:22                   ` K Prateek Nayak
2026-04-21 12:31                     ` Andrea Righi [this message]
2026-04-21 13:38                     ` Andrea Righi
2026-04-22  3:36                       ` K Prateek Nayak
2026-04-22 15:29                         ` Andrea Righi
2026-04-21 12:26                   ` Vincent Guittot
2026-04-21 12:33                     ` Andrea Righi
2026-04-17  9:39   ` Vincent Guittot
2026-04-18  6:02     ` Andrea Righi
2026-04-19 10:20       ` Vincent Guittot
2026-04-03  5:31 ` [PATCH 2/2] sched/fair: Reject misfit pulls onto busy SMT siblings on asym-capacity Andrea Righi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aeduKWloTY86JYgy@gpd4 \
    --to=arighi@nvidia.com \
    --cc=balbirs@nvidia.com \
    --cc=bsegall@google.com \
    --cc=christian.loehle@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=fabecassis@nvidia.com \
    --cc=juri.lelli@redhat.com \
    --cc=kobak@nvidia.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sshegde@linux.ibm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.