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

[Christian Loehle]

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.