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>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Neeraj Upadhyay <neeraj.upadhyay@amd.com>,
Steven Rostedt <rostedt@goodmis.org>,
Uladzislau Rezki <urezki@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>, rcu <rcu@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Kent Overstreet <kent.overstreet@linux.dev>,
bpf@vger.kernel.org, Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>,
Frederic Weisbecker <frederic@kernel.org>
Subject: [PATCH 02/16] srcu: Rename srcu_might_be_idle() to srcu_should_expedite()
Date: Tue, 12 Nov 2024 15:51:45 +0100 [thread overview]
Message-ID: <20241112145159.23032-3-frederic@kernel.org> (raw)
In-Reply-To: <20241112145159.23032-1-frederic@kernel.org>
From: "Paul E. McKenney" <paulmck@kernel.org>
SRCU auto-expedites grace periods that follow a sufficiently long idle
period, and the srcu_might_be_idle() function is used to make this
decision. However, the upcoming light-weight SRCU readers will not do
auto-expediting because doing so would cause the grace-period machinery
to invoke synchronize_rcu_expedited() twice, with IPIs all around.
However, software-engineering considerations force this determination
to remain in srcu_might_be_idle().
This commit therefore changes the name of srcu_might_be_idle() to
srcu_should_expedite(), thus moving from what it currently does to why
it does it, this latter being more future-proof.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: <bpf@vger.kernel.org>
Reviewed-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
kernel/rcu/srcutree.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index 78afaffd1b26..2fe0abade9c0 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -1139,7 +1139,8 @@ static void srcu_flip(struct srcu_struct *ssp)
}
/*
- * If SRCU is likely idle, return true, otherwise return false.
+ * If SRCU is likely idle, in other words, the next SRCU grace period
+ * should be expedited, return true, otherwise return false.
*
* Note that it is OK for several current from-idle requests for a new
* grace period from idle to specify expediting because they will all end
@@ -1159,7 +1160,7 @@ static void srcu_flip(struct srcu_struct *ssp)
* negligible when amortized over that time period, and the extra latency
* of a needlessly non-expedited grace period is similarly negligible.
*/
-static bool srcu_might_be_idle(struct srcu_struct *ssp)
+static bool srcu_should_expedite(struct srcu_struct *ssp)
{
unsigned long curseq;
unsigned long flags;
@@ -1469,14 +1470,15 @@ EXPORT_SYMBOL_GPL(synchronize_srcu_expedited);
* Implementation of these memory-ordering guarantees is similar to
* that of synchronize_rcu().
*
- * If SRCU is likely idle, expedite the first request. This semantic
- * was provided by Classic SRCU, and is relied upon by its users, so TREE
- * SRCU must also provide it. Note that detecting idleness is heuristic
- * and subject to both false positives and negatives.
+ * If SRCU is likely idle as determined by srcu_should_expedite(),
+ * expedite the first request. This semantic was provided by Classic SRCU,
+ * and is relied upon by its users, so TREE SRCU must also provide it.
+ * Note that detecting idleness is heuristic and subject to both false
+ * positives and negatives.
*/
void synchronize_srcu(struct srcu_struct *ssp)
{
- if (srcu_might_be_idle(ssp) || rcu_gp_is_expedited())
+ if (srcu_should_expedite(ssp) || rcu_gp_is_expedited())
synchronize_srcu_expedited(ssp);
else
__synchronize_srcu(ssp, true);
--
2.46.0
next prev parent reply other threads:[~2024-11-12 14:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-12 14:51 [PATCH 00/16] SRCU for v6.13 Frederic Weisbecker
2024-11-12 14:51 ` [PATCH 01/16] srcu: Replace WARN_ON_ONCE() with BUILD_BUG_ON() if possible Frederic Weisbecker
2024-11-12 14:51 ` Frederic Weisbecker [this message]
2024-11-12 14:51 ` [PATCH 03/16] srcu: Introduce srcu_gp_is_expedited() helper function Frederic Weisbecker
2024-11-12 14:51 ` [PATCH 04/16] srcu: Renaming in preparation for additional reader flavor Frederic Weisbecker
2024-11-12 14:51 ` [PATCH 05/16] srcu: Bit manipulation changes " Frederic Weisbecker
2024-11-12 14:51 ` [PATCH 06/16] srcu: Standardize srcu_data pointers to "sdp" and similar Frederic Weisbecker
2024-11-12 14:51 ` [PATCH 07/16] srcu: Improve srcu_read_lock{,_nmisafe}() comments Frederic Weisbecker
2024-11-12 14:51 ` [PATCH 08/16] srcu: Create CPP macros for normal and NMI-safe SRCU readers Frederic Weisbecker
2024-11-12 14:51 ` [PATCH 09/16] srcu: Add srcu_read_lock_lite() and srcu_read_unlock_lite() Frederic Weisbecker
2024-11-12 14:51 ` [PATCH 10/16] srcu: Allow inlining of __srcu_read_{,un}lock_lite() Frederic Weisbecker
2024-11-12 14:51 ` [PATCH 11/16] rcutorture: Expand RCUTORTURE_RDR_MASK_[12] to eight bits Frederic Weisbecker
2024-11-12 14:51 ` [PATCH 12/16] rcutorture: Add reader_flavor parameter for SRCU readers Frederic Weisbecker
2024-11-12 14:51 ` [PATCH 13/16] rcutorture: Add srcu_read_lock_lite() support to rcutorture.reader_flavor Frederic Weisbecker
2024-11-12 14:51 ` [PATCH 14/16] rcutorture: Add light-weight SRCU scenario Frederic Weisbecker
2024-11-12 14:51 ` [PATCH 15/16] refscale: Add srcu_read_lock_lite() support using "srcu-lite" Frederic Weisbecker
2024-11-12 14:51 ` [PATCH 16/16] srcu: Improve srcu_read_lock_lite() kernel-doc comment Frederic Weisbecker
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=20241112145159.23032-3-frederic@kernel.org \
--to=frederic@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=boqun.feng@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=neeraj.upadhyay@amd.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=qiang.zhang1211@gmail.com \
--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 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.