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

[Andrea Righi <arighi@nvidia.com>]

Hi Vincent,

On Thu, Mar 19, 2026 at 08:20:27AM +0100, Vincent Guittot wrote:
> On Wed, 18 Mar 2026 at 18:09, Andrea Righi <arighi@nvidia.com> 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@nvidia.com> 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 ?

Yes, that's correct. More exactly:

                                  speedup %
 ------------------------------+------------
 current asym CPU capacity     |    -
 equal CPU capacity            |  +13.6%
 SMT-aware asym CPU capacity   |  +15.0%

Thanks,
-Andrea