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

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:

quoted

On Wed, Sep 09, 2026 at 08:26:08AM +0200, Andrea Righi wrote:

quoted

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