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

[Phil Auld <pauld@redhat.com>]

On Wed, Mar 25, 2026 at 10:32:28AM +0100 Andrea Righi wrote:
> 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@nvidia.com> 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@arm.com
> > > 
> > > 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@nvidia.com,
> > > 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?
>

That might be a good idea. Especially if it's general and not tied to
EAS/ASYM. I'm getting some requests for something like that. 

CHeers,
Phil


> > 
> > 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
> 

--