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

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello Andrea,

On 9/9/2026 2:19 AM, Andrea Righi wrote:
>> nit. I personally feel this can be better integrated into the
>> sched_balance_find_dst_cpu(). Something like the following:
>>
>>   (Only build tested)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index b8bd308c2d5b..1012dfb33f08 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -12353,6 +12353,17 @@ static inline void update_sg_wakeup_stats(struct sched_domain *sd,
>>  
>>  	}
>>  
>> +	/*
>> +	 * If we are on a SD_SHARE_CPUCAPACITY | SD_ASYM_PACKING
>> +	 * domain, use the group_asym_packing classification to
>> +	 * decide placement based on rankings of idle siblings.
>> +	 */
>> +	if (unlikely(sched_smt_asym_active() &&
>> +		     (sd->flags & SD_SHARE_CPUCAPACITY) &&
>> +		     (sd->flags & SD_ASYM_PACKING) &&
>> +		     sgs->idle_cpus))
>> +		sgs->group_asym_packing = 1;
> 
> Integrating the preference in the slow-path selection sounds appealing, but I
> don't think group_asym_packing can be used as a destination classificaiton here.
> 
> The intended policy is to prefer PE0 over PE1 when both siblings of the selected
> SMT core are idle. And if PE0 is busy, PE1 should remain a valid destination. It
> shouldn't make a busy PE0 preferable to an idle PE1.
> 
> IIUC group_type is ordered for busiest-group selection, group_asym_packing
> describes a source group whole load should be moved to a "more preferred" CPU.
> Marking an idle SMT group as group_asym_packing could make it rank worse than a
> fully busy group.
> 
> Example: a fork on SMT2 can have the busy local PE0 classified as
> group_has_spare or group_fully_busy, while the idle PE1 is forced to
> group_asym_packing, sched_balance_find_dst_group() can then consider the busy
> local group the better destination and stack the new task on PE0. That may
> preserve one-thread mode for a short task, but it can also reduce throughput for
> sustained work.

Ah! Sorry for not realizing that earlier. Probably needs a special case in
"group_has_spare" instead of using the "group_asym_packing" which is always
considered busier than some other classifications but we can always work on
it later.

For now, I can confirm that this shows no performance impact on systems
I've tested this on (4th gen EPYC, and a 128C Ampere ARM server) and the
fast-paths are inlined correctly into select_task_rq_fair() so feel free to
include:

Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>

-- 
Thanks and Regards,
Prateek