From: Andrea Righi <arighi@nvidia.com>
To: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Will Deacon <will@kernel.org>
Cc: 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>,
Christian Loehle <christian.loehle@arm.com>,
Srikar Dronamraju <srikar@linux.ibm.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Phil Auld <pauld@redhat.com>, Breno Leitao <leitao@debian.org>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Lee Trager <ltrager@nvidia.com>, Vikram Sethi <vsethi@nvidia.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v6 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus
Date: Thu, 17 Sep 2026 16:05:19 +0200 [thread overview]
Message-ID: <20260917140707.3807229-1-arighi@nvidia.com> (raw)
NVIDIA Olympus implements SMT with two symmetric processing elements (PEs).
When only one PE is active, the core operates in single-thread mode and that PE
can use the full core resources. When both PEs are active, the core operates in
two-thread mode and the PEs share those resources. This behavior is common to
SMT implementations, but Olympus is particularly sensitive to brief sibling
activations because returning from two-thread mode to single-thread mode after a
sibling becomes idle is not immediate. As described by commit 293f9611ae735
("sched/fair: Prefer fully idle cores for NOHZ balancing"):
Briefly activating an otherwise idle sibling can reduce the
performance available to the other sibling and this effect does not
necessarily end once the activated sibling becomes idle: after the ILB
finishes and its CPU enters WFI, full single-thread performance is
restored only after the sibling has remained idle for a qualification
interval (10 Ki cycles on the tested Vera system).
That change prevents the NOHZ idle load balancer from unnecessarily waking a
sibling of a busy PE. However, ordinary task placement can still select either
sibling of an idle core. Repeatedly changing the active PE can therefore keep
Olympus cores in two-thread mode despite little or no useful overlap between the
siblings.
The first patch teaches the fair scheduler's idle-selection paths to honor
SD_ASYM_PACKING at the shared-capacity SMT level. The scheduler first selects a
candidate CPU and core according to its existing placement and capacity rules,
then chooses the highest-priority available sibling within that core. This also
completes the existing POWER7 SD_ASYM_PACKING behavior by applying its
hardware-thread ordering during idle selection.
Olympus firmware does not currently provide an interface to describe the
preferred SMT sibling. Adding such a firmware or ACPI interface will take time
and will not help systems with existing firmware. At the same time, inferring
this policy from MIDR would encode a platform-specific decision in the kernel
and make it harder to replace with a proper firmware ABI.
The second patch therefore adds the sched_smt_asym_packing= boot option. Using
sched_smt_asym_packing=on explicitly opts the SMT scheduling domain into
SD_ASYM_PACKING without requiring architecture-specific detection. Priority
remains defined by arch_asym_cpu_priority(). The weak default orders siblings by
-cpu, consistently selecting the lowest-numbered available logical CPU.
Architecture overrides remain authoritative, so siblings assigned equal
priorities remain unordered. The default auto mode preserves
architecture-provided topology policy, including the existing powerpc behavior,
while off provides an explicit override to disable SMT asymmetric packing.
On Olympus, PE0 and PE1 have equal steady-state capacity; this preference does
not identify a faster PE. The lower-numbered logical CPU is used only as a
canonical choice when both siblings are available. Consistently selecting the
same sibling avoids alternating the active PE across wakeups, lets the other
sibling remain idle for longer, and allows more cores to remain in, or return
to, full-resource single-thread mode.
The v6 series was tested on a two-node Vera system using 88-thread
single-precision GEMM workloads on the 88 physical cores of NUMA node 0, with
sched_smt_asym_packing=on and the workloads allowed to choose either sibling of
every core. Each result covers five runs.
Two BLAS implementations were tested: OpenBLAS, an open-source BLAS library that
provides a publicly reproducible benchmark, and NVIDIA Performance Libraries
(NVPL), NVIDIA's optimized BLAS implementation.
OpenBLAS was evaluated using benchmark/sgemm.goto with an M=N=K=16384
single-precision GEMM. NVPL was evaluated using benchblas with the same matrix
dimensions, non-transposed inputs, alpha=1 and beta=0. The numbers below are the
mean and standard deviation from five runs.
OpenBLAS throughput increased from 7.11876 +/- 0.06734 TFLOP/s on the baseline
kernel to 7.34669 +/- 0.01936 TFLOP/s with this series (+3.20%). NVPL throughput
increased from 9.64742 +/- 0.17311 TFLOP/s to 10.29695 +/- 0.01786 TFLOP/s
(+6.73%).
The lower standard deviation also shows that the results became more
predictable. With the series applied, the workloads consistently settled on the
lower-numbered sibling, allowing the other sibling to remain idle.
Changes in v6:
- Drop the arm64 MIDR-based enablement and arch_asym_cpu_priority()
override (Will Deacon)
- Add the generic sched_smt_asym_packing={auto,on,off} boot option
- Use the default -cpu priority ordering instead of interpreting MPIDR
- Drop the SMT-specific asymmetric-packing static key and use
sched_smt_active() (Vincent Guittot)
- Link to v5: https://lore.kernel.org/r/20260909062649.469633-1-arighi@nvidia.com
Changes in v5:
- Remove the redundant olympus_prefer_pe0 state (K Prateek Nayak)
- Link to v4: https://lore.kernel.org/r/20260908082345.103087-1-arighi@nvidia.com
Changes in v4:
- Honor the SMT sibling priority in the slow path (Srikar Dronamraju)
- Rename the consolidated helper to select_idle_smt_cpu()
(Srikar Dronamraju)
- Link to v3: https://lore.kernel.org/r/20260907163513.4172411-1-arighi@nvidia.com
Changes in v3:
- Consolidate the SMT-priority adjustment in select_idle_sibling()
after an idle candidate has been selected (K Prateek Nayak)
- Fold the asym SMT checks into select_idle_smt_priority() and scan the
scheduling-domain span directly (K Prateek Nayak)
- Link to v2: https://lore.kernel.org/r/20260904091838.3617894-1-arighi@nvidia.com
Changes in v2:
- Clarify that the generic scheduler change also covers POWER7
(Dietmar Eggemann)
- Simplify sched_smt_asym_prefer() by inspecting the lowest scheduling
domain directly (Dietmar Eggemann)
- Link to v1: https://lore.kernel.org/r/20260831181800.1668646-1-arighi@nvidia.com
Andrea Righi (2):
sched/fair: Honor asymmetric SMT priority in idle selection
sched/topology: Add asymmetric SMT packing override
Documentation/admin-guide/kernel-parameters.txt | 11 ++++
kernel/sched/fair.c | 85 ++++++++++++++++++++-----
kernel/sched/topology.c | 49 ++++++++++++++
3 files changed, 128 insertions(+), 17 deletions(-)
next reply other threads:[~2026-09-17 14:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 14:05 Andrea Righi [this message]
2026-09-17 14:05 ` [PATCH 1/2] sched/fair: Honor asymmetric SMT priority in idle selection Andrea Righi
2026-09-17 16:55 ` Kayra Cizmeci
2026-09-18 6:28 ` Kayra Cizmeci
2026-09-17 14:05 ` [PATCH 2/2] sched/topology: Add asymmetric SMT packing override 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=20260917140707.3807229-1-arighi@nvidia.com \
--to=arighi@nvidia.com \
--cc=bsegall@google.com \
--cc=christian.loehle@arm.com \
--cc=corbet@lwn.net \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=leitao@debian.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltrager@nvidia.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=skhan@linuxfoundation.org \
--cc=srikar@linux.ibm.com \
--cc=sshegde@linux.ibm.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=vsethi@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®