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

[Andrea Righi <arighi@nvidia.com>]

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@nvidia.com> wrote:
> >>>
> >>> On some platforms, the firmware may expose per-CPU performance
> >>> differences (e.g., via ACPI CPPC highest_perf) even when the system is
> >>> effectively symmetric. These small variations, typically due to silicon
> >>> binning, are reflected in arch_scale_cpu_capacity() and end up being
> >>> interpreted as real capacity asymmetry.
> >>>
> >>> As a result, the scheduler incorrectly enables SD_ASYM_CPUCAPACITY,
> >>> triggering asymmetry-specific behaviors, even though all CPUs have
> >>> comparable performance.
> >>>
> >>> Prevent this by treating CPU capacities within 20% of the maximum value
> >>
> >> 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...

> 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