All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Righi <arighi@nvidia.com>
To: Christian Loehle <christian.loehle@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Shrikanth Hegde <sshegde@linux.ibm.com>,
	Phil Auld <pauld@redhat.com>, Breno Leitao <leitao@debian.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] arm64: topology: Prefer PE0 on NVIDIA Olympus SMT cores
Date: Mon, 31 Aug 2026 23:43:43 +0200	[thread overview]
Message-ID: <apX1j6srdTcFLZOd@gpd4> (raw)
In-Reply-To: <f5d625d0-3b94-407c-8f64-793df9590f03@arm.com>

Hi Christian,

On Mon, Aug 31, 2026 at 10:13:42PM +0100, Christian Loehle wrote:
> On 8/31/26 19:10, Andrea Righi wrote:
> > NVIDIA Olympus implements spatial SMT with symmetric steady-state PE
> > capacity but two different resource modes. One-Thread Active mode gives
> > one PE the full core, while waking the other PE restores Two-Thread
> > Active mode and partitions decode, issue, cache, TLB, and vector
> > resources. Returning to full-resource mode requires the sibling to
> > remain in WFI for 10 Ki cycles.
> > 
> > Measurements show that pinned workloads perform equally on either PE,
> > but freely migratable workloads lose substantial throughput when they
> > alternate between PE identities. Consistently selecting PE0 keeps PE1
> > idle, avoids repeated SMT repartitioning, and restores one-thread-per-core
> > performance.
> > 
> > Describe this scheduling preference with SD_ASYM_PACKING and give PE0,
> > identified by MPIDR_EL1.Aff0, the higher arch_asym_cpu_priority(). This is
> > independent of SD_ASYM_CPUCAPACITY: SMT siblings retain equal capacity,
> > while physical cores with different maximum frequencies are handled by
> > a higher scheduling domain.
> 
> But why? This asympacking + CAS interaction is a bit hard to comprehend IMV.

The two mehcanisms describe different preferences at different scheduling domain
levels: SD_ASYM_CPUCAPACITY selects among physical cores with different max
capacities, SD_ASYM_PACKING is set only on the SMT domain and selects the
canonical PE within the core chose by the existing placement and capacity logic.

> Why can't we encode both preferences in the asym-packing priority, e.g.
> 
> priority(cpu) = is_primary(cpu) ? 2 * highest_perf(cpu)
>                                 : highest_perf(cpu)
> 
> so that all primary PEs are preferred over all sibling PEs, while still
> preserving the highest_perf ordering within each group, and do away with
> SD_ASYM_CPUCAPACITY on Vera altogether?

I can experiment with this combined priority, but I think removing
SD_ASYM_CPUCAPACITY is a separate policy change rather than an alternative
implementation of this fix.

A static asym-packing priority does not preserve the capacity-aware semantics
used for task fitting, uclamp, misfit handling and migration. The current
approach keeps those semantics when selecting a physical core, then applies the
PE preference only within that core.

Also, encoding the combined priority alone would not fix the problem addressed
by patch 2: the idle-selection paths currently do not consult asymmetric SMT
priority. They can still return an arbitrary idle sibling regardless of how
arch_asym_cpu_priority() is defined. Patch 2 adds that missing behavior and
scopes it to the shared-capacity SMT domain.

> I had suggested this a while ago, did you have a stab at that by any chance,
> too?

I tested your CPPC-based asym-packing series, but not this particular
combined-priority variant. IIUC the earlier proposal was replacing
capacity-aware scheduling for minor physical-core capacity differences, SMT
sibling ordering looks like an orthogonal problem.

And at the time, the combined SMT-aware SD_ASYM_CPUCAPACITY approach also gave
the best Vera results of the alternatives I tested, which is another reason I
kept physical-core capacity selection separate here.

> Am I missing something altogether?

Combining the priorities is a valid experiment, but I'm not sure if it
completely solves the problem by itself, I'll give it a try and share the
results.

Thanks,
-Andrea

> 
> > 
> > Firmware currently provides no interface for describing the preferred
> > SMT sibling. Detect Olympus by MIDR until such an interface is available.
> > 
> > Signed-off-by: Andrea Righi <arighi@nvidia.com>
> > ---
> >  arch/arm64/include/asm/topology.h |  1 +
> >  arch/arm64/kernel/smp.c           |  1 +
> >  arch/arm64/kernel/topology.c      | 62 +++++++++++++++++++++++++++++++
> >  3 files changed, 64 insertions(+)
> > > 
> > diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> > index b9eaf4ad70850..edc1c59b3448d 100644
> > --- a/arch/arm64/include/asm/topology.h
> > +++ b/arch/arm64/include/asm/topology.h
> > @@ -18,6 +18,7 @@ int pcibus_to_node(struct pci_bus *bus);
> >  #include <linux/arch_topology.h>
> >  
> >  void update_freq_counters_refs(void);
> > +void arm64_init_sched_topology(void);
> >  
> >  /* Replace task scheduler's default frequency-invariant accounting */
> >  #define arch_scale_freq_tick topology_scale_freq_tick
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index a61dc3016a117..0135ac4eea8bd 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -443,6 +443,7 @@ void __init smp_cpus_done(unsigned int max_cpus)
> >  	hyp_mode_check();
> >  	setup_system_features();
> >  	setup_user_features();
> > +	arm64_init_sched_topology();
> >  	mark_linear_text_alias_ro();
> >  }
> >  
> > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> > index d28438f8b83f1..0dd9eec1c4946 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,66 @@
> >  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.
> > + */
> > +static bool olympus_prefer_pe0 __ro_after_init;
> > +
> > +#ifdef CONFIG_SCHED_SMT
> > +static int arm64_smt_flags(void)
> > +{
> > +	int flags = cpu_smt_flags();
> > +
> > +	if (olympus_prefer_pe0)
> > +		flags |= SD_ASYM_PACKING;
> > +
> > +	return flags;
> > +}
> > +#endif
> > +
> > +static struct sched_domain_topology_level arm64_asym_smt_topology[] = {
> > +#ifdef CONFIG_SCHED_SMT
> > +	SDTL_INIT(tl_smt_mask, arm64_smt_flags, SMT),
> > +#endif
> > +#ifdef CONFIG_SCHED_CLUSTER
> > +	SDTL_INIT(tl_cls_mask, cpu_cluster_flags, CLS),
> > +#endif
> > +#ifdef CONFIG_SCHED_MC
> > +	SDTL_INIT(tl_mc_mask, cpu_core_flags, MC),
> > +#endif
> > +	SDTL_INIT(tl_pkg_mask, NULL, PKG),
> > +	{ NULL, },
> > +};
> > +
> > +void __init arm64_init_sched_topology(void)
> > +{
> > +	if (!IS_ENABLED(CONFIG_SCHED_SMT))
> > +		return;
> > +
> > +	if ((read_cpuid_id() & MIDR_CPU_MODEL_MASK) != MIDR_NVIDIA_OLYMPUS)
> > +		return;
> > +
> > +	if (!topology_core_has_smt(smp_processor_id()))
> > +		return;
> > +
> > +	olympus_prefer_pe0 = true;
> > +	set_sched_topology(arm64_asym_smt_topology);
> > +	pr_info("Enabling PE0 SMT preference for NVIDIA Olympus\n");
> > +}
> > +
> > +int arch_asym_cpu_priority(int cpu)
> > +{
> > +	if (!olympus_prefer_pe0)
> > +		return 0;
> > +
> > +	return MPIDR_AFFINITY_LEVEL(cpu_logical_map(cpu), 0) == 0;
> > +}
> > +
> >  struct amu_cntr_sample {
> >  	u64		arch_const_cycles_prev;
> >  	u64		arch_core_cycles_prev;
> 


  reply	other threads:[~2026-08-31 21:44 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31 18:10 [PATCH 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-08-31 18:10 ` [PATCH 1/2] arm64: topology: Prefer PE0 on NVIDIA Olympus SMT cores Andrea Righi
2026-08-31 21:13   ` Christian Loehle
2026-08-31 21:43     ` Andrea Righi [this message]
2026-09-01  6:05       ` Andrea Righi
2026-09-01  8:32       ` Christian Loehle
2026-09-01 19:38         ` Andrea Righi
2026-08-31 18:10 ` [PATCH 2/2] sched/fair: Honor asymmetric SMT priority in idle selection Andrea Righi
2026-09-03 10:59   ` Dietmar Eggemann
2026-09-04  5:59     ` Andrea Righi
  -- strict thread matches above, loose matches on Subject: below --
2026-09-04  9:18 [PATCH v2 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-09-04  9:18 ` [PATCH 1/2] arm64: topology: Prefer PE0 on NVIDIA Olympus SMT cores Andrea Righi
2026-09-07 16:30 [PATCH v3 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-09-07 16:30 ` [PATCH 1/2] arm64: topology: Prefer PE0 on NVIDIA Olympus SMT cores Andrea Righi
2026-09-08  8:23 [PATCH v4 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-09-08  8:23 ` [PATCH 1/2] arm64: topology: Prefer PE0 on NVIDIA Olympus SMT cores Andrea Righi
2026-09-08 20:09   ` K Prateek Nayak
2026-09-08 20:57     ` Andrea Righi
2026-09-09  6:26 [PATCH v5 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-09-09  6:26 ` [PATCH 1/2] arm64: topology: Prefer PE0 on NVIDIA Olympus SMT cores Andrea Righi
2026-09-09 15:19   ` Dietmar Eggemann
2026-09-09 16:17     ` Andrea Righi
2026-09-10 10:11       ` Dietmar Eggemann
2026-09-11  9:11         ` Andrea Righi
2026-09-11 14:15           ` Dietmar Eggemann
2026-09-09 15:34   ` Will Deacon
2026-09-09 16:07     ` Andrea Righi
2026-09-10  8:53       ` Will Deacon
2026-09-11  6:50         ` Andrea Righi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=apX1j6srdTcFLZOd@gpd4 \
    --to=arighi@nvidia.com \
    --cc=bsegall@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=christian.loehle@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=leitao@debian.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=pauld@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sshegde@linux.ibm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.