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

[Andrea Righi]

On Thu, Sep 10, 2026 at 09:53:38AM +0100, Will Deacon wrote:
> 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!

I try to be a good citizen every now and then. :)

> 
> > 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.

Awesome! I'll work through Dietmar's point for this and post a new version
without the MIDR-based detection.

Thanks,
-Andrea