From: Frederic Weisbecker <frederic@kernel.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
Boqun Feng <boqun.feng@gmail.com>,
Joel Fernandes <joel@joelfernandes.org>,
Josh Triplett <josh@joshtriplett.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Neeraj Upadhyay <neeraj.upadhyay@amd.com>,
Steven Rostedt <rostedt@goodmis.org>,
Uladzislau Rezki <urezki@gmail.com>, rcu <rcu@vger.kernel.org>,
Frederic Weisbecker <frederic@kernel.org>
Subject: [PATCH 16/23] locktorture: Add call_rcu_chains module parameter
Date: Tue, 10 Oct 2023 13:59:14 +0200 [thread overview]
Message-ID: <20231010115921.988766-17-frederic@kernel.org> (raw)
In-Reply-To: <20231010115921.988766-1-frederic@kernel.org>
From: "Paul E. McKenney" <paulmck@kernel.org>
When running locktorture on large systems, there will normally be
enough RCU activity to ensure that there is a grace period in flight
at all times. However, on smaller systems, RCU might well be idle the
majority of the time. This situation can be inconvenient in cases where
the RCU CPU stall warning is part of the debugging process.
This commit therefore adds an call_rcu_chains module parameter to
locktorture, allowing the user to specify the desired number of
self-propagating call_rcu() chains. For good measure, immediately
before invoking call_rcu(), the self-propagating RCU callback invokes
start_poll_synchronize_rcu() to force the immediate start of a grace
period, with the call_rcu() forcing another to start shortly thereafter.
Booting with locktorture.call_rcu_chains=2 increases the probability
of a stuck locking primitive resulting in an RCU CPU stall warning from
about 25% to nearly 100%.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
.../admin-guide/kernel-parameters.txt | 7 +++
kernel/locking/locktorture.c | 62 ++++++++++++++++++-
2 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 0a1731a0f0ef..300e2c30986c 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2913,6 +2913,13 @@
to extract confidential information from the kernel
are also disabled.
+ locktorture.call_rcu_chains= [KNL]
+ Specify the number of self-propagating call_rcu()
+ chains to set up. These are used to ensure that
+ there is a high probability of an RCU grace period
+ in progress at any given time. Defaults to 0,
+ which disables these call_rcu() chains.
+
locktorture.nreaders_stress= [KNL]
Set the number of locking read-acquisition kthreads.
Defaults to being automatically set based on the
diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
index d2a3a8cc1902..01d56e6c44d7 100644
--- a/kernel/locking/locktorture.c
+++ b/kernel/locking/locktorture.c
@@ -34,6 +34,7 @@ MODULE_LICENSE("GPL");
MODULE_AUTHOR("Paul E. McKenney <paulmck@linux.ibm.com>");
torture_param(int, acq_writer_lim, 0, "Write_acquisition time limit (jiffies).");
+torture_param(int, call_rcu_chains, 0, "Self-propagate call_rcu() chains during test (0=disable).");
torture_param(int, long_hold, 100, "Do occasional long hold of lock (ms), 0=disable");
torture_param(int, nested_locks, 0, "Number of nested locks (max = 8)");
torture_param(int, nreaders_stress, -1, "Number of read-locking stress-test threads");
@@ -119,6 +120,12 @@ struct lock_stress_stats {
long n_lock_acquired;
};
+struct call_rcu_chain {
+ struct rcu_head crc_rh;
+ bool crc_stop;
+};
+struct call_rcu_chain *call_rcu_chain;
+
/* Forward reference. */
static void lock_torture_cleanup(void);
@@ -1037,15 +1044,60 @@ lock_torture_print_module_parms(struct lock_torture_ops *cur_ops,
cpumask_setall(&cpumask_all);
pr_alert("%s" TORTURE_FLAG
- "--- %s%s: acq_writer_lim=%d long_hold=%d nested_locks=%d nreaders_stress=%d nwriters_stress=%d onoff_holdoff=%d onoff_interval=%d rt_boost=%d rt_boost_factor=%d shuffle_interval=%d shutdown_secs=%d stat_interval=%d stutter=%d verbose=%d writer_fifo=%d readers_bind=%*pbl writers_bind=%*pbl\n",
+ "--- %s%s: acq_writer_lim=%d call_rcu_chains=%d long_hold=%d nested_locks=%d nreaders_stress=%d nwriters_stress=%d onoff_holdoff=%d onoff_interval=%d rt_boost=%d rt_boost_factor=%d shuffle_interval=%d shutdown_secs=%d stat_interval=%d stutter=%d verbose=%d writer_fifo=%d readers_bind=%*pbl writers_bind=%*pbl\n",
torture_type, tag, cxt.debug_lock ? " [debug]": "",
- acq_writer_lim, long_hold, nested_locks, cxt.nrealreaders_stress,
+ acq_writer_lim, call_rcu_chains, long_hold, nested_locks, cxt.nrealreaders_stress,
cxt.nrealwriters_stress, onoff_holdoff, onoff_interval, rt_boost,
rt_boost_factor, shuffle_interval, shutdown_secs, stat_interval, stutter,
verbose, writer_fifo,
cpumask_pr_args(rcmp), cpumask_pr_args(wcmp));
}
+// If requested, maintain call_rcu() chains to keep a grace period always
+// in flight. These increase the probability of getting an RCU CPU stall
+// warning and associated diagnostics when a locking primitive stalls.
+
+static void call_rcu_chain_cb(struct rcu_head *rhp)
+{
+ struct call_rcu_chain *crcp = container_of(rhp, struct call_rcu_chain, crc_rh);
+
+ if (!smp_load_acquire(&crcp->crc_stop)) {
+ (void)start_poll_synchronize_rcu(); // Start one grace period...
+ call_rcu(&crcp->crc_rh, call_rcu_chain_cb); // ... and later start another.
+ }
+}
+
+// Start the requested number of call_rcu() chains.
+static int call_rcu_chain_init(void)
+{
+ int i;
+
+ if (call_rcu_chains <= 0)
+ return 0;
+ call_rcu_chain = kcalloc(call_rcu_chains, sizeof(*call_rcu_chain), GFP_KERNEL);
+ if (!call_rcu_chains)
+ return -ENOMEM;
+ for (i = 0; i < call_rcu_chains; i++) {
+ call_rcu_chain[i].crc_stop = false;
+ call_rcu(&call_rcu_chain[i].crc_rh, call_rcu_chain_cb);
+ }
+ return 0;
+}
+
+// Stop all of the call_rcu() chains.
+static void call_rcu_chain_cleanup(void)
+{
+ int i;
+
+ if (!call_rcu_chain)
+ return;
+ for (i = 0; i < call_rcu_chains; i++)
+ smp_store_release(&call_rcu_chain[i].crc_stop, true);
+ rcu_barrier();
+ kfree(call_rcu_chain);
+ call_rcu_chain = NULL;
+}
+
static void lock_torture_cleanup(void)
{
int i;
@@ -1096,6 +1148,8 @@ static void lock_torture_cleanup(void)
kfree(cxt.lrsa);
cxt.lrsa = NULL;
+ call_rcu_chain_cleanup();
+
end:
if (cxt.init_called) {
if (cxt.cur_ops->exit)
@@ -1225,6 +1279,10 @@ static int __init lock_torture_init(void)
}
}
+ firsterr = call_rcu_chain_init();
+ if (torture_init_error(firsterr))
+ goto unwind;
+
lock_torture_print_module_parms(cxt.cur_ops, "Start of test");
/* Prepare torture context. */
--
2.34.1
next prev parent reply other threads:[~2023-10-10 12:07 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 11:58 [PATCH 00/23] RCU/lock torture updates for v6.7 Frederic Weisbecker
2023-10-10 11:58 ` [PATCH 01/23] torture: Share torture_random_state with torture_shuffle_tasks() Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 02/23] torture: Make kvm-recheck.sh use mktemp Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 03/23] torture: Make torture_hrtimeout_ns() take an hrtimer mode parameter Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 04/23] rcu: Include torture_sched_setaffinity() declaration Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 05/23] torture: Move rcutorture_sched_setaffinity() out of rcutorture Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 06/23] locktorture: Add readers_bind and writers_bind module parameters Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 07/23] rcutorture: Add CONFIG_DEBUG_OBJECTS to RCU Tasks testing Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 08/23] rcutorture: Fix stuttering races and other issues Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 09/23] locktorture: Alphabetize torture_param() entries Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 10/23] locktorture: Consolidate "if" statements in lock_torture_writer() Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 11/23] locktorture: Add acq_writer_lim to complain about long acquistion times Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 12/23] rcutorture: Copy out ftrace into its own console file Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 13/23] torture: Print out torture module parameters Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 14/23] torture: Make torture.sh refscale testing qualify verbose_batched Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 15/23] locktorture: Add new module parameters to lock_torture_print_module_parms() Frederic Weisbecker
2023-10-10 11:59 ` Frederic Weisbecker [this message]
2023-10-10 11:59 ` [PATCH 17/23] doc: Catch-up update for locktorture module parameters Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 18/23] locktorture: Rename readers_bind/writers_bind to bind_readers/bind_writers Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 19/23] torture: Add kvm.sh --debug-info argument Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 20/23] rcutorture: Replace schedule_timeout*() 1-jiffy waits with HZ/20 Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 21/23] rcutorture: Traverse possible cpu to set maxcpu in rcu_nocb_toggle() Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 22/23] torture: Convert parse-console.sh to mktemp Frederic Weisbecker
2023-10-10 11:59 ` [PATCH 23/23] locktorture: Check the correct variable for allocation failure Frederic Weisbecker
2023-10-10 13:55 ` Paul E. McKenney
2023-10-10 14:07 ` Dan Carpenter
2023-10-10 15:53 ` Paul E. McKenney
2023-10-11 6:46 ` Dan Carpenter
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=20231010115921.988766-17-frederic@kernel.org \
--to=frederic@kernel.org \
--cc=boqun.feng@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=neeraj.upadhyay@amd.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--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