Re: [PATCH] sched/topology: Avoid spurious asymmetry from CPU capacity noise
From: Phil Auld
Date: Wed Mar 25 2026 - 08:58:47 EST
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@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?
>
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
>
--