[PATCH 2/2] sched/fair: Honor asymmetric SMT priority in idle selection

Andrea Righi arighi at nvidia.com
Mon Sep 7 02:50:31 PDT 2026


On Mon, Sep 07, 2026 at 03:10:00PM +0530, K Prateek Nayak wrote:
...
> >> @@ -9043,27 +9049,31 @@ static int select_idle_sibling(struct task_struct *p, int prev, int target)
> >>  
> >>  		if (!has_idle_core && cpus_share_cache(prev, target)) {
> >>  			i = select_idle_smt(p, sd, prev);
> >> -			if ((unsigned int)i < nr_cpumask_bits)
> >> -				return i;
> >> +			if ((unsigned int)i < nr_cpumask_bits) {
> >> +				target = i;
> >> +				goto out;
> >> +			}
> >>  		}
> >>  	}
> >>  
> >>  	i = select_idle_cpu(p, sd, has_idle_core, target);
> >>  	if ((unsigned)i < nr_cpumask_bits)
> >> -		return i;
> >> -
> >> +		target = i;
> > 
> > Not sure about this final fallback. Is it worth doing an additional
> > select_idle_smt_priority() after idle scan failed or stopped because the
> > SIS_UTIL scan budget was exhausted?
> 
> I see what you mean! We'll end up doing a:
> 
>   select_idle_smt_priority(p, target)
> 
> at the end which might indeed be wasteful.

Exactly.

> > 
> > It seems better to jump to out only when one of these paths has actually
> > selected a candidate:
> > 
> > 	i = select_idle_cpu(p, sd, has_idle_core, target);
> > 	if ((unsigned int)i < nr_cpumask_bits) {
> > 		target = i;
> > 		goto out;
> > 	}
> > 
> > The prev_aff and recent_used_cpu fallbacks can jump to "out" as well, since they
> > were already verified as suitable candidates. If none of those paths succeeds, I
> > think the existing final "return target" should remain unchanged.
> > 
> > Does that make sense?
> 
> Correct me if I'm wrong but you are suggesting to keep the current
> return intact and put out label after it like:
> 
>     /* If no suitable target was found */
>     return target;
> 
> out:
>    if (!sched_smt_asym_active())
>        return target;
> 
>    return select_idle_smt_priority(p, target);
> ---
> 
> That makes sense to me!

Correct, I'm going to run some tests with this and will send a v3 later.

Thanks!
-Andrea



More information about the linux-arm-kernel mailing list