Re: [PATCH] sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection

[Christian Loehle]

On 3/18/26 10:31, Andrea Righi wrote:
> Hi Vincent,
> 
> On Wed, Mar 18, 2026 at 10:41:15AM +0100, Vincent Guittot wrote:
>> On Wed, 18 Mar 2026 at 10:22, Andrea Righi <arighi@xxxxxxxxxx> wrote:
>>>
>>> On systems with asymmetric CPU capacity (e.g., ACPI/CPPC reporting
>>> different per-core frequencies), the wakeup path uses
>>> select_idle_capacity() and prioritizes idle CPUs with higher capacity
>>> for better task placement. However, when those CPUs belong to SMT cores,
>>
>> Interesting, which kind of system has both SMT and SD_ASYM_CPUCAPACITY
>> ? I thought both were never set simultaneously and SD_ASYM_PACKING was
>> used for system involving SMT like x86
> 
> It's an NVIDIA platform (not publicly available yet), where the firmware
> exposes different CPU capacities and has SMT enabled, so both
> SD_ASYM_CPUCAPACITY and SMT are present. I'm not sure whether the final
> firmware release will keep this exact configuration (there's a good chance
> it will), so I'm targeting it to be prepared.


Andrea,
that makes me think, I've played with a nvidia grace available to me recently,
which sets slightly different CPPC highest_perf values (~2%) which automatically
will set SD_ASYM_CPUCAPACITY and run the entire capacity-aware scheduling
machinery for really almost negligible capacity differences, where it's
questionable how sensible that is.
I have an arm64 + CPPC implementation for asym-packing for this machine, maybe
we can reuse that for here too?
(Given that really capacity and SMT are contradicting, e.g. a physical core with
1024 capacity but 4 threads may give you a lot lower observed CPU capacity than
a 512 nosmt core per (logical) CPU depending on how much the sibling threads are
utilized.)

> [snip]