Re: [RFC][RFT][PATCH 0/3] arm64: Enable asympacking for minor CPPC asymmetry

[Christian Loehle]

On 3/26/26 08:24, Vincent Guittot wrote:
> On Thu, 26 Mar 2026 at 09:16, Christian Loehle <christian.loehle@xxxxxxx> wrote:
>>
>> On 3/26/26 07:53, Vincent Guittot wrote:
>>> On Wed, 25 Mar 2026 at 19:13, Christian Loehle <christian.loehle@xxxxxxx> wrote:
>>>>
>>>> The scheduler currently handles CPU performance asymmetry via either:
>>>>
>>>> - SD_ASYM_PACKING: simple priority-based task placement (x86 ITMT)
>>>> - SD_ASYM_CPUCAPACITY: capacity-aware scheduling
>>>>
>>>> On arm64, capacity-aware scheduling is used for any detected capacity
>>>> differences.
>>>>
>>>> Some systems expose small per-CPU performance differences via CPPC
>>>> highest_perf (e.g. due to chip binning), resulting in slightly different
>>>> capacities (<~5%). These differences are sufficient to trigger
>>>> SD_ASYM_CPUCAPACITY, even though the system is otherwise effectively
>>>> symmetric.
>>>>
>>>> For such small deltas, capacity-aware scheduling is unnecessarily
>>>> complex. A simpler priority-based approach, similar to x86 ITMT, is
>>>> sufficient.
>>>
>>> I'm not convinced that moving to  SD_ASYM_PACKING is the right way to
>>> move forward.
>>> t
>>> 1st of all, do you target all kind of system or only SMT? It's not
>>> clear in your cover letter
>>
>> AFAIK only Andrea has access to an unreleased asymmetric SMT system,
>> I haven't done any tests on such a system (as the cover-letter mentions
>> under RFT section).
>>
>>>
>>> Moving on asym pack for !SMT doesn't make sense to me. If you don't
>>> want EAS enabled, you can disable it with
>>> /proc/sys/kernel/sched_energy_aware
>>
>> Sorry, what's EAS got to do with it? The system I care about here
>> (primarily nvidia grace) has no EM.
> 
> I tried to understand the end goal of this patch
> 
> SD_ASYM_CPUCAPACITY works fine with !SMT system so why enabling
> SD_ASYM_PACKING for <5% diff ?
> 
> That doesn't make sense to me
I don't know if "works fine" describes the situation accurately.
I guess I should've included the context in the cover letter, but you
are aware of them (you've replied to them anyway):
https://lore.kernel.org/lkml/20260324005509.1134981-1-arighi@xxxxxxxxxx/
https://lore.kernel.org/lkml/20260318092214.130908-1-arighi@xxxxxxxxxx/

Andrea sees an improvement even when force-equalizing CPUs to remove
SD_ASYM_CPUCAPACITY, so I'd argue it doesn't "work fine" on these platforms.
To me it seems more reasonable to attempt to get these minor improvements
of minor asymmetries through asympacking and leave SD_ASYM_CPUCAPACITY
to the actual 'true' asymmetry (e.g. different uArch or vastly different
performance levels).
SD_ASYM_CPUCAPACITY handling is also arguably broken if no CPU pair in
the system fulfills capacity_greater(), the call sites in fair.c give
a good overview.
Is $subject the right approach to deal with these platforms instead?
I don't know, that's why it's marked RFC and RFT.