From: "Paul E. McKenney" <paulmck@kernel.org>
To: rcu@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com,
mingo@kernel.org, jiangshanlai@gmail.com,
akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org,
rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com,
fweisbec@gmail.com, oleg@redhat.com, joel@joelfernandes.org,
Frederic Weisbecker <frederic@kernel.org>,
Valentin Schneider <valentin.schneider@arm.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Boqun Feng <boqun.feng@gmail.com>,
Neeraj Upadhyay <neeraju@codeaurora.org>,
Uladzislau Rezki <urezki@gmail.com>,
"Paul E . McKenney" <paulmck@kernel.org>
Subject: [PATCH rcu 07/18] rcu/nocb: Check a stable offloaded state to manipulate qlen_last_fqs_check
Date: Wed, 1 Dec 2021 16:29:01 -0800 [thread overview]
Message-ID: <20211202002912.3127710-7-paulmck@kernel.org> (raw)
In-Reply-To: <20211202002848.GA3127439@paulmck-ThinkPad-P17-Gen-1>
From: Frederic Weisbecker <frederic@kernel.org>
It's not entirely obvious why rdp->qlen_last_fqs_check is updated before
processing the queue only on offloaded rdp. There can be different
effect to that, either in favour of triggering the force quiescent state
path or not. For example:
1) If the number of callbacks has decreased since the last
rdp->qlen_last_fqs_check update (because we recently called
rcu_do_batch() and we executed below qhimark callbacks) and the number
of processed callbacks on a subsequent do_batch() arranges for
exceeding qhimark on non-offloaded but not on offloaded setup, then we
may spare a later run to the force quiescent state
slow path on __call_rcu_nocb_wake(), as compared to the non-offloaded
counterpart scenario.
Here is such an offloaded scenario instance:
qhimark = 1000
rdp->last_qlen_last_fqs_check = 3000
rcu_segcblist_n_cbs(rdp) = 2000
rcu_do_batch() {
if (offloaded)
rdp->last_qlen_fqs_check = rcu_segcblist_n_cbs(rdp) // 2000
// run 1000 callback
rcu_segcblist_n_cbs(rdp) = 1000
// Not updating rdp->qlen_last_fqs_check
if (count < rdp->qlen_last_fqs_check - qhimark)
rdp->qlen_last_fqs_check = count;
}
call_rcu() * 1001 {
__call_rcu_nocb_wake() {
// not taking the fqs slowpath:
// rcu_segcblist_n_cbs(rdp) == 2001
// rdp->qlen_last_fqs_check == 2000
// qhimark == 1000
if (len > rdp->qlen_last_fqs_check + qhimark)
...
}
In the case of a non-offloaded scenario, rdp->qlen_last_fqs_check
would be 1000 and the fqs slowpath would have executed.
2) If the number of callbacks has increased since the last
rdp->qlen_last_fqs_check update (because we recently queued below
qhimark callbacks) and the number of callbacks executed in rcu_do_batch()
doesn't exceed qhimark for either offloaded or non-offloaded setup,
then it's possible that the offloaded scenario later run the force
quiescent state slow path on __call_rcu_nocb_wake() while the
non-offloaded doesn't.
qhimark = 1000
rdp->last_qlen_last_fqs_check = 3000
rcu_segcblist_n_cbs(rdp) = 2000
rcu_do_batch() {
if (offloaded)
rdp->last_qlen_last_fqs_check = rcu_segcblist_n_cbs(rdp) // 2000
// run 100 callbacks
// concurrent queued 100
rcu_segcblist_n_cbs(rdp) = 2000
// Not updating rdp->qlen_last_fqs_check
if (count < rdp->qlen_last_fqs_check - qhimark)
rdp->qlen_last_fqs_check = count;
}
call_rcu() * 1001 {
__call_rcu_nocb_wake() {
// Taking the fqs slowpath:
// rcu_segcblist_n_cbs(rdp) == 3001
// rdp->qlen_last_fqs_check == 2000
// qhimark == 1000
if (len > rdp->qlen_last_fqs_check + qhimark)
...
}
In the case of a non-offloaded scenario, rdp->qlen_last_fqs_check
would be 3000 and the fqs slowpath would have executed.
The reason for updating rdp->qlen_last_fqs_check when invoking callbacks
for offloaded CPUs is that there is usually no point in waking up either
the rcuog or rcuoc kthreads while in this state. After all, both threads
are prohibited from indefinite sleeps.
The exception is when some huge number of callbacks are enqueued while
rcu_do_batch() is in the midst of invoking, in which case interrupting
the rcuog kthread's timed sleep might get more callbacks set up for the
next grace period.
Reported-and-tested-by: Valentin Schneider <valentin.schneider@arm.com>
Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Original-patch-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Neeraj Upadhyay <neeraju@codeaurora.org>
Cc: Uladzislau Rezki <urezki@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
---
kernel/rcu/tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index cb9abb80377fe..4cbfc4e4fa9ed 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2498,7 +2498,7 @@ static void rcu_do_batch(struct rcu_data *rdp)
trace_rcu_batch_start(rcu_state.name,
rcu_segcblist_n_cbs(&rdp->cblist), bl);
rcu_segcblist_extract_done_cbs(&rdp->cblist, &rcl);
- if (offloaded)
+ if (rcu_rdp_is_offloaded(rdp))
rdp->qlen_last_fqs_check = rcu_segcblist_n_cbs(&rdp->cblist);
trace_rcu_segcb_stats(&rdp->cblist, TPS("SegCbDequeued"));
--
2.31.1.189.g2e36527f23
next prev parent reply other threads:[~2021-12-02 0:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-02 0:28 [PATCH rcu 0/18] RCU no-CBs CPU updates for v5.17 Paul E. McKenney
2021-12-02 0:28 ` [PATCH rcu 01/18] rcu: Tighten rcu_advance_cbs_nowake() checks Paul E. McKenney
2021-12-02 0:41 ` Frederic Weisbecker
2021-12-02 0:55 ` Paul E. McKenney
2021-12-02 0:28 ` [PATCH rcu 02/18] rcu/nocb: Make local rcu_nocb_lock_irqsave() safe against concurrent deoffloading Paul E. McKenney
2021-12-02 0:28 ` [PATCH rcu 03/18] rcu/nocb: Prepare state machine for a new step Paul E. McKenney
2021-12-02 0:28 ` [PATCH rcu 04/18] rcu/nocb: Invoke rcu_core() at the start of deoffloading Paul E. McKenney
2021-12-02 0:28 ` [PATCH rcu 05/18] rcu/nocb: Make rcu_core() callbacks acceleration preempt-safe Paul E. McKenney
2021-12-02 0:29 ` [PATCH rcu 06/18] rcu/nocb: Make rcu_core() callbacks acceleration (de-)offloading safe Paul E. McKenney
2021-12-02 0:29 ` Paul E. McKenney [this message]
2021-12-02 0:29 ` [PATCH rcu 08/18] rcu/nocb: Use appropriate rcu_nocb_lock_irqsave() Paul E. McKenney
2021-12-02 0:29 ` [PATCH rcu 09/18] rcu/nocb: Limit number of softirq callbacks only on softirq Paul E. McKenney
2021-12-02 0:29 ` [PATCH rcu 10/18] rcu: Fix callbacks processing time limit retaining cond_resched() Paul E. McKenney
2021-12-02 0:29 ` [PATCH rcu 11/18] rcu: Apply callbacks processing time limit only on softirq Paul E. McKenney
2021-12-02 0:29 ` [PATCH rcu 12/18] rcu/nocb: Don't invoke local rcu core on callback overload from nocb kthread Paul E. McKenney
2021-12-02 0:29 ` [PATCH rcu 13/18] rcu/nocb: Remove rcu_node structure from nocb list when de-offloaded Paul E. McKenney
2021-12-02 0:29 ` [PATCH rcu 14/18] rcu/nocb: Prepare nocb_cb_wait() to start with a non-offloaded rdp Paul E. McKenney
2021-12-02 0:29 ` [PATCH rcu 15/18] rcu/nocb: Optimize kthreads and rdp initialization Paul E. McKenney
2021-12-02 0:29 ` [PATCH rcu 16/18] rcu/nocb: Create kthreads on all CPUs if "rcu_nocbs=" or "nohz_full=" are passed Paul E. McKenney
2021-12-02 0:29 ` [PATCH rcu 17/18] rcu/nocb: Allow empty "rcu_nocbs" kernel parameter Paul E. McKenney
2021-12-02 0:29 ` [PATCH rcu 18/18] rcu/nocb: Merge rcu_spawn_cpu_nocb_kthread() and rcu_spawn_one_nocb_kthread() Paul E. McKenney
2021-12-02 2:03 ` [PATCH rcu 0/18] RCU no-CBs CPU updates for v5.17 Yury Norov
2021-12-02 18:01 ` Paul E. McKenney
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=20211202002912.3127710-7-paulmck@kernel.org \
--to=paulmck@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=frederic@kernel.org \
--cc=fweisbec@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=neeraju@codeaurora.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=urezki@gmail.com \
--cc=valentin.schneider@arm.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