Re: [PATCH 1/2] arm64: topology: Prefer PE0 on NVIDIA Olympus SMT cores

[Will Deacon]

On Wed, Sep 09, 2026 at 06:07:04PM +0200, Andrea Righi wrote:
> On Wed, Sep 09, 2026 at 04:34:18PM +0100, Will Deacon wrote:
> > On Wed, Sep 09, 2026 at 08:26:08AM +0200, Andrea Righi wrote:
> > > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> > > index d28438f8b83f1..e5a7a4b2e3844 100644
> > > --- a/arch/arm64/kernel/topology.c
> > > +++ b/arch/arm64/kernel/topology.c
> > > @@ -19,6 +19,8 @@
> > >  #include <linux/init.h>
> > >  #include <linux/percpu.h>
> > >  #include <linux/sched/isolation.h>
> > > +#include <linux/sched/topology.h>
> > > +#include <linux/smp.h>
> > >  #include <linux/xarray.h>
> > >  
> > >  #include <asm/cpu.h>
> > > @@ -44,6 +46,55 @@
> > >  static DEFINE_PER_CPU_READ_MOSTLY(unsigned long, arch_max_freq_scale) =  1UL << (2 * SCHED_CAPACITY_SHIFT);
> > >  static cpumask_var_t amu_fie_cpus;
> > >  
> > > +/*
> > > + * Switching the active PE on an NVIDIA Olympus SMT core can keep the core in
> > > + * two-thread active mode, with resources partitioned between the PEs.
> > > + *
> > > + * Prefer PE0 so PE1 can remain idle and the core can stay in full-resource
> > > + * mode. Firmware does not currently describe this preference, so detect
> > > + * Olympus by MIDR until a firmware interface is available.
> > > + */
> > 
> > Fix the firmware?
> > 
> > If we add this MIDR kludge, I guarantee that it will never be fixed.
> 
> Understood. The existing PPTT already describes the SMT relationship, but as far
> as I can tell ACPI doesn't currently provide a way to describe a preferred SMT
> sibling. Both PEs also have equal isolated performance, so representing this
> using different _CPC highest_perf values wouldn't accurately describe their
> capacity.
> 
> I'll drop the MIDR-based enablement and coordinate with the firmware team on a
> proper ABI.

Thanks, Andrea, I must confess that I wasn't expecting that!

> In the meantime, for systems with the existing firmware, would an explicit
> kernel boot option be acceptable as a fallback? It'd enable SD_ASYM_PACKING at
> the SMT level and prefer the primary PE, but only when requested by the user;
> the kernel would not infer this policy from the CPU model.

I'm ok with that.

Will