Re: [PATCH] sched/fair: Stabilize idle SMT core selection with asym-capacity

[Julia Lawall]

> On 3 Jul 2026, at 08:34, Andrea Righi <arighi@xxxxxxxxxx> wrote:
> 
> On Fri, Jul 03, 2026 at 11:40:28AM +0200, Andrea Righi wrote:
> ...
>>>> On NVIDIA Vera Rubin (arm64, 176 CPUs/88 cores per NUMA node), a
>>>> CPU-intensive NVPL SGEMM workload restricted to 88 threads (one per
>>>> core) showed a consistent 23% increase in mean throughput across
>>>> multiple runs.
>>> 
>>> Interesting! This reads like active balance across cores is not aggressive
>>> enough for this workload and, as a result, stacking somehow helps.
>>> 
>>> I would have expected balance within the core would trigger first and that
>>> would just lead to the same scenario as both sibling sibling busy but I
>>> guess there is a higher order effect of stacking.
>> 
>> I think the key here is that temporary runqueue stacking is preferable to
>> consuming both SMT siblings when fully-idle SMT cores are available, more than
>> having benfits from the stacking itself.
>> 
>>> 
>>> perf sched stats reports for this workload before and after
>>> applying your patch may help to see what changes for the load
>>> balancer to start doing better.
>> 
>> Ack, I'll collect some perf stats and share.
>> 
> 
> I collected some perf sched stats diff with mainline vs patched kernel, here's a
> quick recap of the benchmark results + stats (I can also share all the detailed
> stats if you prefer):
>                                 mainline    patched
>  elapsed jiffies                  17472      13808
>  average GFLOP/s                6297.62    8423.60
>  sched_yield calls               11.47M      4.47M
>  run delay / runtime              0.20%      0.31%
>  timeslices                         168        562
> 
>  Across SMT, MC and NUMA domains:
>    *_lb_gained                       0          0
>    alb_pushed                        0          0
>    ttwu_move_balance                 0          0
> 
> The schedstat comparison doesn't show the load balancer moving any potential
> stacked tasks: *_lb_gained, alb_pushed and ttwu_move_balance remain 0 across the
> domains. So the gain doesn't come from post-wakeup balancing.
> 
> The only clear difference is that the sched_yield() rate drops by approximately
> 51%, this might explain the speedup, but the stats don't expose the CPU selected
> by select_idle_capacity(), so it can't directly prove if the placement
> was beneficial. I'll collect more stats.

Maybe look at a trace with perfetto ?

> 
> Thanks,
> -Andrea