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

[Andrea Righi <arighi@nvidia.com>]

Hi Christian,

On Mon, Jul 06, 2026 at 12:40:58PM +0100, Christian Loehle wrote:
> On 7/3/26 18:07, Andrea Righi wrote:
> > 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).
> 
> Thanks for the explanation, interesting...
> So maybe we can fold the entire highest_perf thing into that, too, so you end up
> just with SD_ASYM_PACKING and not
> SD_ASYM_PACKING (for SMT sibling asymmetry)+CAS(for highest_perf core asymmetry),
> I think that would be a lot cleaner.

I think so. I need to try combining this with your SD_ASYM_PACKING series.

This is what I’m currently experimenting with, if you're curious (still WIP):
 git://git.kernel.org/pub/scm/linux/kernel/git/arighi/linux.git vr-smt

Thanks,
-Andrea