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

[Andrea Righi <arighi@nvidia.com>]

On Fri, Jul 03, 2026 at 06:54:14PM +0200, Peter Zijlstra wrote:
> On Fri, Jul 03, 2026 at 04:52:17PM +0200, Andrea Righi wrote:
> 
> > 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.
> 
> Cute, that's something that Power7 also had. That's where
> SD_ASYM_PACKING originated from.

Yep, I'm actually experimenting with a patch that mimics the Power7 and it
seems to work. :) But I'm using a quirk to detect the particular CPU
implementation to set SD_ASYM_PACKING on the SMT domain and assign a higher
arch_asym_cpu_priority() to the first sibling, which is not the best...

So I'm checking with the firmware folks whether they can expose the relative SMT
thread priority explicitly, so that the kernel can discover the asymmetry and
the preferred sibling, instead of relying on CPU type and enumeration order
(considering that there are also multiple SMT configurations that can alter this
asymmetry... it's not just SMT on/off).

That said, we can ignore this patch for now. I'll come up with a better
solution, hopefully.

Thanks,
-Andrea