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

[Andrea Righi <arighi@nvidia.com>]

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.

Thanks,
-Andrea