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

[Andrea Righi <arighi@nvidia.com>]

Hi Will,

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.

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.

Other ideas?

Thanks,
-Andrea