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

[Andrea Righi <arighi@nvidia.com>]

Hi Koba,

On Wed, Mar 25, 2026 at 11:30:48AM +0800, Koba Ko wrote:
> On Tue, Mar 24, 2026 at 10:39:41AM +0100, Andrea Righi wrote:
> > Hi Vincent,
> > 
> > On Tue, Mar 24, 2026 at 08:39:34AM +0100, 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?
> > 
> > Sure, 5% seems a more reasonable margin. I'll just reuse capacity_greater()
> > as suggested by Christian.
> > 
> > Thanks,
> > -Andrea
> > 
> 
> How about modifying asym_cpu_capacity_update_data to group all CPUs within 5% capacity difference into the same group?
> ```
> +#define capacity_greater(cap1, cap2) ((cap1) * 1024 > (cap2) * 1078)
> 
>         list_for_each_entry(entry, &asym_cap_list, link) {
> -               if (capacity == entry->capacity)
> +               if (!capacity_greater(capacity, entry->capacity) &&
> +                   !capacity_greater(entry->capacity, capacity))

Yeah, makes sense, I like this better than mine. But there's still the
concern of potentially regressing other systems, nullifying the small
asym-capacity benefits (as Chris mentioned here:
https://lore.kernel.org/r/15ffdeb3-a0f3-4b88-92c0-17ffb03b0574@arm.com).

Thanks,
-Andrea