Re: [PATCH] sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection

[Vincent Guittot]

On Wed, 18 Mar 2026 at 18:09, Andrea Righi <arighi@xxxxxxxxxx> wrote:
>
> Hi Christian,
>
> On Wed, Mar 18, 2026 at 03:43:26PM +0000, Christian Loehle wrote:
> > On 3/18/26 10:31, Andrea Righi wrote:
> > > Hi Vincent,
> > >
> > > On Wed, Mar 18, 2026 at 10:41:15AM +0100, Vincent Guittot wrote:
> > >> On Wed, 18 Mar 2026 at 10:22, Andrea Righi <arighi@xxxxxxxxxx> wrote:
> > >>>
> > >>> On systems with asymmetric CPU capacity (e.g., ACPI/CPPC reporting
> > >>> different per-core frequencies), the wakeup path uses
> > >>> select_idle_capacity() and prioritizes idle CPUs with higher capacity
> > >>> for better task placement. However, when those CPUs belong to SMT cores,
> > >>
> > >> Interesting, which kind of system has both SMT and SD_ASYM_CPUCAPACITY
> > >> ? I thought both were never set simultaneously and SD_ASYM_PACKING was
> > >> used for system involving SMT like x86
> > >
> > > It's an NVIDIA platform (not publicly available yet), where the firmware
> > > exposes different CPU capacities and has SMT enabled, so both
> > > SD_ASYM_CPUCAPACITY and SMT are present. I'm not sure whether the final
> > > firmware release will keep this exact configuration (there's a good chance
> > > it will), so I'm targeting it to be prepared.
> >
> >
> > Andrea,
> > that makes me think, I've played with a nvidia grace available to me recently,
> > which sets slightly different CPPC highest_perf values (~2%) which automatically
> > will set SD_ASYM_CPUCAPACITY and run the entire capacity-aware scheduling
> > machinery for really almost negligible capacity differences, where it's
> > questionable how sensible that is.
>
> That looks like the same system that I've been working with. I agree that
> treating small CPPC differences as full asymmetry can be a bit overkill.
>
> I've been experimenting with flattening the capacities (to force the
> "regular" idle CPU selection policy), which performs better than the
> current asym-capacity CPU selection. However, adding the SMT awareness to
> the asym-capacity, seems to give a consistent +2-3% (same set of
> CPU-intensive benchmarks) compared to flatening alone, which is not bad.

Do you mean that this patch is +2% > vs plain SMP  > than current asym
cpucapacity implementation ?

>
> > I have an arm64 + CPPC implementation for asym-packing for this machine, maybe
> > we can reuse that for here too?
>
> Sure, that sounds interesting, if it's available somewhere I'd be happy to
> do some testing.
>
> Thanks,
> -Andrea