From: Vishal Chourasia <vishalc@linux.ibm.com>
To: peterz@infradead.org, aboorvad@linux.ibm.com
Cc: boqun.feng@gmail.com, frederic@kernel.org, joelagnelf@nvidia.com,
josh@joshtriplett.org, linux-kernel@vger.kernel.org,
neeraj.upadhyay@kernel.org, paulmck@kernel.org,
rcu@vger.kernel.org, rostedt@goodmis.org, srikar@linux.ibm.com,
sshegde@linux.ibm.com, tglx@linutronix.de, urezki@gmail.com,
samir@linux.ibm.com, vishalc@linux.ibm.com
Subject: [PATCH v3 0/2] cpuhp: Improve SMT switch time via lock batching and RCU expedition
Date: Wed, 18 Feb 2026 14:09:14 +0530 [thread overview]
Message-ID: <20260218083915.660252-2-vishalc@linux.ibm.com> (raw)
On large systems with high core counts, toggling SMT modes via sysfs
(/sys/devices/system/cpu/smt/control) incurs significant latency. For
instance, on ~2000 CPUs, switching SMT modes can take close to an hour
as the system hotplugs each hardware thread individually. This series
reduces this time to minutes.
Analysis of the hotplug path [1] identifies synchronize_rcu() as the
primary bottleneck. During a bulk SMT switch, the kernel repeatedly
enters RCU grace periods for each CPU being brought online or offline.
This series optimizes the SMT transition in two ways:
1. Lock Batching [1]: Instead of repeatedly acquiring and releasing the CPU
hotplug write lock for every individual CPU, we now hold cpus_write_lock
across the entire SMT toggle operation.
2. Expedite RCU grace period [2]: It utilizes rcu_expedite_gp() to force
expedite grace periods specifically for the duration of the SMT switch.
The trade-off is justified here to prevent the administrative task of
SMT switching from stalling for an unacceptable duration on large
systems.
Changes since v1
Link: https://lore.kernel.org/all/20260112094332.66006-2-vishalc@linux.ibm.com/
Expedite system-wide synchronize_rcu only when SMT switch operation are
triggered via /sys/devices/system/cpu/smt/control interface.
Changes since v2
Link: https://lore.kernel.org/all/20260216121927.489062-2-vishalc@linux.ibm.com/
Move the declaration of rcu_[un]expedite_gp() to
include/linux/rcupdate.h. Thanks Shrikanth for sharing the fix and
kernel test robot for finding the issue. [3]
[1] https://lore.kernel.org/all/5f2ab8a44d685701fe36cdaa8042a1aef215d10d.camel@linux.vnet.ibm.com
[2] https://lore.kernel.org/all/20260113090153.GS830755@noisy.programming.kicks-ass.net/
[3] https://lore.kernel.org/all/202602170049.WQD7Wcuj-lkp@intel.com/
Vishal Chourasia (2):
cpuhp: Optimize SMT switch operation by batching lock acquisition
cpuhp: Expedite RCU grace periods during SMT operations
include/linux/rcupdate.h | 8 +++++
kernel/cpu.c | 76 +++++++++++++++++++++++++++++-----------
kernel/rcu/rcu.h | 4 ---
3 files changed, 64 insertions(+), 24 deletions(-)
--
2.53.0
next reply other threads:[~2026-02-18 8:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-18 8:39 Vishal Chourasia [this message]
2026-02-18 8:39 ` [PATCH v3 1/2] cpuhp: Optimize SMT switch operation by batching lock acquisition Vishal Chourasia
2026-03-25 19:09 ` Thomas Gleixner
2026-03-26 10:06 ` Vishal Chourasia
2026-02-18 8:39 ` [PATCH v3 2/2] cpuhp: Expedite RCU grace periods during SMT operations Vishal Chourasia
2026-02-27 1:13 ` Joel Fernandes
2026-03-02 11:47 ` Samir M
2026-03-06 5:44 ` Vishal Chourasia
2026-03-06 15:12 ` Paul E. McKenney
2026-03-20 18:49 ` Vishal Chourasia
2026-03-25 19:10 ` Thomas Gleixner
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=20260218083915.660252-2-vishalc@linux.ibm.com \
--to=vishalc@linux.ibm.com \
--cc=aboorvad@linux.ibm.com \
--cc=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--cc=joelagnelf@nvidia.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neeraj.upadhyay@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=samir@linux.ibm.com \
--cc=srikar@linux.ibm.com \
--cc=sshegde@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=urezki@gmail.com \
/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