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

[Andrea Righi]

On Wed, Mar 25, 2026 at 10:23:09AM +0100, Dietmar Eggemann wrote:
> On 24.03.26 12:01, Andrea Righi wrote:
> > Hi Dietmar,
> > 
> > On Tue, Mar 24, 2026 at 11:29:24AM +0100, Dietmar Eggemann wrote:
> >> 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:
> 
> [...]
> 
> >> 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
> > 
> > Yeah, I think Chris' asym-packing approach might be the safest thing to do.
> > 
> > At the same time it would be nice to improve asym-capacity to introduce
> > some concept of SMT awareness, that was my original attempt with
> > https://lore.kernel.org/all/20260318092214.130908-1-arighi@xxxxxxxxxx,
> > since we may see similar asym-capacity benefits on Vera (that has SMT,
> > unlike Grace). What do you think?
> 
> We never found a good way to specify a CPU capacity in the SMT case (EAS
> and energy model included). So comparing CPU capacity w/ utilization, CPU
> overutilization detection etc. definitions get more blurry.

Hm... so should we just avoid calling select_idle_capacity() when SMT is
enabled to prevent waking up tasks on both SMT siblings when there are
fully-idle SMT cores?

> 
> But in case you now want to hide these small CPU capacity differences from
> asym-cpucap setup you won't run into this 'SD_SHARE_CPUCAPACITY +
> SD_ASYM_CPUCAPACITY'.
> 
> You still will have small differences in sched group capacities but this
> is covered by load-balance.
> 
> BTW, you should have seen on Vera ?: 
> 
> sd_int() [kernel/sched/.topology.c]
> 
> 1720 WARN_ONCE((sd->flags & (SD_SHARE_CPUCAPACITY | SD_ASYM_CPUCAPACITY)) ==
> 1721                   (SD_SHARE_CPUCAPACITY | SD_ASYM_CPUCAPACITY),
> 1722                   "CPU capacity asymmetry not supported on SMT\n");

Yep, I've seen that. :)

Thanks,
-Andrea