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

Hello Andrea,

On 9/9/2026 2:19 AM, Andrea Righi wrote:

quoted

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