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 v2 2/2] cpuhp: Expedite RCU grace periods during SMT operations
Date: Mon, 16 Feb 2026 17:49:30 +0530 [thread overview]
Message-ID: <20260216121927.489062-6-vishalc@linux.ibm.com> (raw)
In-Reply-To: <20260216121927.489062-2-vishalc@linux.ibm.com>
Expedite synchronize_rcu during the SMT mode switch operation when
initiated via /sys/devices/system/cpu/smt/control interface
SMT mode switch operation i.e. between SMT 8 to SMT 1 or vice versa and
others, are user driven operations and therefore should complete as soon
as possible. Switching SMT states involves iterating over a list of CPUs
and performing hotplug operations. It was found these transitions took
significantly large amount of time to complete particularly on
high-core-count systems because system was blocked on synchronize_rcu
calls.
Below is one of the call-stacks that accounted for most of the blocking
time overhead as reported by offcputime bcc script for CPU offline
operation,
finish_task_switch
__schedule
schedule
schedule_timeout
wait_for_completion
__wait_rcu_gp
synchronize_rcu
cpuidle_uninstall_idle_handler
powernv_cpuidle_cpu_dead
cpuhp_invoke_callback
__cpuhp_invoke_callback_range
_cpu_down
cpu_device_down
cpu_subsys_offline
device_offline
online_store
dev_attr_store
sysfs_kf_write
kernfs_fop_write_iter
vfs_write
ksys_write
system_call_exception
system_call_common
- bash (29705)
5771569 ------------------------> Duration (us)
Signed-off-by: Vishal Chourasia <vishalc@linux.ibm.com>
---
include/linux/rcupdate.h | 3 +++
kernel/cpu.c | 4 ++++
2 files changed, 7 insertions(+)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 7729fef249e1..f12d0d0f008d 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -1190,6 +1190,9 @@ rcu_head_after_call_rcu(struct rcu_head *rhp, rcu_callback_t f)
extern int rcu_expedited;
extern int rcu_normal;
+extern void rcu_expedite_gp(void);
+extern void rcu_unexpedite_gp(void);
+
DEFINE_LOCK_GUARD_0(rcu, rcu_read_lock(), rcu_read_unlock())
DECLARE_LOCK_GUARD_0_ATTRS(rcu, __acquires_shared(RCU), __releases_shared(RCU))
diff --git a/kernel/cpu.c b/kernel/cpu.c
index edaa37419036..f5517d64d3f3 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2683,6 +2683,7 @@ int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
ret = -EBUSY;
goto out;
}
+ rcu_expedite_gp();
/* Hold cpus_write_lock() for entire batch operation. */
cpus_write_lock();
for_each_online_cpu(cpu) {
@@ -2715,6 +2716,7 @@ int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
if (!ret)
cpu_smt_control = ctrlval;
cpus_write_unlock();
+ rcu_unexpedite_gp();
arch_smt_update();
out:
cpu_maps_update_done();
@@ -2734,6 +2736,7 @@ int cpuhp_smt_enable(void)
int cpu, ret = 0;
cpu_maps_update_begin();
+ rcu_expedite_gp();
/* Hold cpus_write_lock() for entire batch operation. */
cpus_write_lock();
cpu_smt_control = CPU_SMT_ENABLED;
@@ -2750,6 +2753,7 @@ int cpuhp_smt_enable(void)
cpuhp_online_cpu_device(cpu);
}
cpus_write_unlock();
+ rcu_unexpedite_gp();
arch_smt_update();
cpu_maps_update_done();
return ret;
--
2.53.0
next prev parent reply other threads:[~2026-02-16 12:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-16 12:19 [PATCH v2 0/2] cpuhp: Improve SMT switch time via lock batching and RCU expedition Vishal Chourasia
2026-02-16 12:19 ` [PATCH v2 1/2] cpuhp: Optimize SMT switch operation by batching lock acquisition Vishal Chourasia
2026-02-16 12:48 ` Vishal Chourasia
2026-02-16 12:57 ` Shrikanth Hegde
2026-02-16 13:28 ` Shrikanth Hegde
2026-02-16 12:19 ` Vishal Chourasia [this message]
2026-02-16 16:05 ` [PATCH v2 2/2] cpuhp: Expedite RCU grace periods during SMT operations kernel test robot
2026-02-16 16:38 ` kernel test robot
2026-02-16 17:10 ` Shrikanth Hegde
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=20260216121927.489062-6-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 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.