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

[Andrea Righi]

Hi Christian,

On Fri, Jul 03, 2026 at 11:00:23AM +0100, Christian Loehle wrote:
...
> > 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.
> > 
> I'm curious now, as a not at all SMT expert, this is super counterintuitive to me,
> am I missing something? How does this happen?
> The SMT-switch should be way less overhead than the task context-switch, no?

As mentioned in my other email, I found a surprising asymmetry on this machine:
pinning one worker per core to the first SMT siblings gives substantially better
performance than pinning them to the second siblings, despite firmware
advertising identical capacity and frequency for both.

Since this change uses cpumask_first_and() as the stable representative, it also
strongly biases placement toward the faster first siblings. That may explain
much of the observed improvement independently of whether temporary stacking
helps the load balancer.

I haven't yet established that stacking two tasks on sibling 0 is better than
running one task on each sibling simultaneously. Also, the latter is not really
an SMT “switch”: both threads run concurrently and compete for shared execution
and memory resources, whereas stacking involves normal scheduler time-sharing
and context switches.

Once I figure out exactly why this machine has SMT asymmetry, I'll share the
details. :)

Thanks,
-Andrea