Re: [PATCH] sched/topology: Avoid spurious asymmetry from CPU capacity noise

[Dietmar Eggemann]

On 24.03.26 10:46, Andrea Righi wrote:
> Hi Christian,
> 
> On Tue, Mar 24, 2026 at 08:08:22AM +0000, Christian Loehle wrote:
>> On 3/24/26 07:55, Christian Loehle wrote:
>>> On 3/24/26 07:39, Vincent Guittot wrote:
>>>> On Tue, 24 Mar 2026 at 01:55, Andrea Righi <arighi@xxxxxxxxxx> wrote:

[...]

>>>> 20% is a bit high, my snapdragon rb5 has a mid CPU with a capacity of
>>>> 871 but we still want to keep them different
>>>>
>>>> Why would 5% not be enough?
>>>
>>> I've also used 5%, or rather the existing capacity_greater() macro.
>>
>> Also, given that this patch even mentions this as "noise" one might ask
>> why the firmware wouldn't force-equalise this.
> 
> I think it's reasonable to consider that as "noise" from a scheduler
> perspective, but from a hardware/firmware point of view I don't have strong
> arguments to propose equalizing the highest_perf values. At the end, at
> least in my case, it seems all compliant with the ACPI/CPPC specs and
> suggesting to equalize them because "the kernel doesn't handle it well"
> doesn't seem like a solid motivation...

The first time we observed this on NVIDIA Grace, we wondered whether
there might be functionality outside the task scheduler that makes use
of these slightly heterogeneous CPU capacity values from CPPC—and
whether the dependency on task scheduling was simply an overlooked
phenomenon.

And then there was DCPerf Mediawiki on 72 CPUs system always scoring
better with sched_asym_cpucap_active() = TRUE (mentioned already by
Chris L. in:
https://lore.kernel.org/r/15ffdeb3-a0f3-4b88-92c0-17ffb03b0574@xxxxxxx

>> Anyway let me finally send out those asympacking patches which would make
>> that issue obsolete because we actually make use of the highest_perf
>> information from the firmware.
> 
> Looking forward to that. :)
> 
> Thanks,
> -Andrea