Re: [PATCH v3 1/4] sched/fair: Check CPU capacity before comparing group types during load balance

[Ricardo Neri]

On Fri, May 15, 2026 at 08:29:28PM +0800, Chen, Yu C wrote:
> On 5/15/2026 2:34 AM, Ricardo Neri wrote:
> 
> [ ... ]
> 
> > @@ -10818,6 +10818,20 @@ static bool update_sd_pick_busiest(struct lb_env *env,
> >   	     sds->local_stat.group_type != group_has_spare))
> >   		return false;
> > +	/*
> > +	 * Candidate sg has no more than one task per CPU and has higher
> > +	 * per-CPU capacity. Migrating tasks to less capable CPUs may harm
> > +	 * throughput. Maximize throughput, power/energy consequences are not
> > +	 * considered.
> > +	 *
> > +	 * Systems with SMT are unaffected, as asymmetric capacity is not set
> > +	 * in such cases.
> > +	 */
> 
> Does "SMT" here imply that group_smt_balance is unaffected?
> Regardless of whether we move the check earlier, this seems to
> already be guaranteed by the fact that the check only applies
> to sgs->group_type <= group_fully_busy, which does not include
> group_smt_balance. In other words, SD_ASYM_CPUCAPACITY is not
> the only gatekeeper.

This comment is instead about domains having both SD_ASYM_CPUCAPACITY and
SD_SHARE_CPUCAPACITY. Today these flags are mutually exclusive, but that
change. There have been patches proposing to make asymmetric capacity SMT-
aware.

In any case, I think this check still holds, because we are skipping
groups up to fully_busy that have greater capacity than dst_cpu.

> 
> Other than that, the change looks good to me,Reviewed-by: Chen Yu
> <yu.c.chen@xxxxxxxxx>

Thank you!

> 
> thanks,
> Chenyu
> > +	if ((env->sd->flags & SD_ASYM_CPUCAPACITY) &&
> > +	    (sgs->group_type <= group_fully_busy) &&
> > +	    (capacity_greater(sg->sgc->min_capacity, capacity_of(env->dst_cpu))))
> > +		return false;
> > +
>