Re: [RFC][RFT][PATCH 0/3] arm64: Enable asympacking for minor CPPC asymmetry

[Vincent Guittot]

On Thu, 26 Mar 2026 at 09:16, Christian Loehle <christian.loehle@xxxxxxx> wrote:
>
> On 3/26/26 07:53, Vincent Guittot wrote:
> > On Wed, 25 Mar 2026 at 19:13, Christian Loehle <christian.loehle@xxxxxxx> wrote:
> >>
> >> The scheduler currently handles CPU performance asymmetry via either:
> >>
> >> - SD_ASYM_PACKING: simple priority-based task placement (x86 ITMT)
> >> - SD_ASYM_CPUCAPACITY: capacity-aware scheduling
> >>
> >> On arm64, capacity-aware scheduling is used for any detected capacity
> >> differences.
> >>
> >> Some systems expose small per-CPU performance differences via CPPC
> >> highest_perf (e.g. due to chip binning), resulting in slightly different
> >> capacities (<~5%). These differences are sufficient to trigger
> >> SD_ASYM_CPUCAPACITY, even though the system is otherwise effectively
> >> symmetric.
> >>
> >> For such small deltas, capacity-aware scheduling is unnecessarily
> >> complex. A simpler priority-based approach, similar to x86 ITMT, is
> >> sufficient.
> >
> > I'm not convinced that moving to  SD_ASYM_PACKING is the right way to
> > move forward.
> > t
> > 1st of all, do you target all kind of system or only SMT? It's not
> > clear in your cover letter
>
> AFAIK only Andrea has access to an unreleased asymmetric SMT system,
> I haven't done any tests on such a system (as the cover-letter mentions
> under RFT section).
>
> >
> > Moving on asym pack for !SMT doesn't make sense to me. If you don't
> > want EAS enabled, you can disable it with
> > /proc/sys/kernel/sched_energy_aware
>
> Sorry, what's EAS got to do with it? The system I care about here
> (primarily nvidia grace) has no EM.

I tried to understand the end goal of this patch

SD_ASYM_CPUCAPACITY works fine with !SMT system so why enabling
SD_ASYM_PACKING for <5% diff ?

That doesn't make sense to me

>
> >
> > For SMT system and small capacity difference, I would prefer that we
> > look at supporting SMT in SD_ASYM_CPUCAPACITY. Starting with
> > select_idle_capacity
>
> This series is actually targeted for primarily the !SMT case, although
> it may or may not be useful for some of the SMT woes, too!
> (Again, I wouldn't know, I don't have such a system to test with)
>
> >[snip]