public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: rcu@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com,
	rostedt@goodmis.org, "Paul E. McKenney" <paulmck@kernel.org>,
	Brian Foster <bfoster@redhat.com>,
	Dave Chinner <david@fromorbit.com>,
	Al Viro <viro@zeniv.linux.org.uk>, Ian Kent <raven@themaw.net>
Subject: [PATCH rcu 01/12] rcu: Make normal polling GP be more precise about sequence numbers
Date: Mon, 20 Jun 2022 15:51:17 -0700	[thread overview]
Message-ID: <20220620225128.3842050-1-paulmck@kernel.org> (raw)
In-Reply-To: <20220620224943.GA3841634@paulmck-ThinkPad-P17-Gen-1>

Currently, poll_state_synchronize_rcu() uses rcu_seq_done() to check
whether the specified grace period has completed.  However, rcu_seq_done()
does a simple comparison that reserves have of the sequence-number space
for uncompleted grace periods.  This has the unfortunate side-effect
of not handling sequence-number wrap gracefully.  Of course, one can
argue that if someone has already waited for half of the full range of
grace periods, they can wait for the other half, but why wait at all in
this case?

This commit therefore creates a rcu_seq_done_exact() that counts as
uncompleted only the two grace periods during which the sequence number
might have been handed out, while still being uncompleted.  This way,
if sequence-number wrap happens to hit that range, at most two additional
grace periods need be waited for.

This commit is in preparation for polled expedited grace periods.

Link: https://lore.kernel.org/all/20220121142454.1994916-1-bfoster@redhat.com/
Link: https://docs.google.com/document/d/1RNKWW9jQyfjxw2E8dsXVTdvZYh0HnYeSHDKog9jhdN8/edit?usp=sharing
Cc: Brian Foster <bfoster@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Ian Kent <raven@themaw.net>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
---
 kernel/rcu/rcu.h  | 12 ++++++++++++
 kernel/rcu/tree.c |  4 ++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
index 4916077119f3f..0adb55941aeb3 100644
--- a/kernel/rcu/rcu.h
+++ b/kernel/rcu/rcu.h
@@ -119,6 +119,18 @@ static inline bool rcu_seq_done(unsigned long *sp, unsigned long s)
 	return ULONG_CMP_GE(READ_ONCE(*sp), s);
 }
 
+/*
+ * Given a snapshot from rcu_seq_snap(), determine whether or not a
+ * full update-side operation has occurred, but do not allow the
+ * (ULONG_MAX / 2) safety-factor/guard-band.
+ */
+static inline bool rcu_seq_done_exact(unsigned long *sp, unsigned long s)
+{
+	unsigned long cur_s = READ_ONCE(*sp);
+
+	return ULONG_CMP_GE(cur_s, s) || ULONG_CMP_LT(cur_s, s - (2 * RCU_SEQ_STATE_MASK + 1));
+}
+
 /*
  * Has a grace period completed since the time the old gp_seq was collected?
  */
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index c25ba442044a6..ec28e259774e7 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3911,7 +3911,7 @@ EXPORT_SYMBOL_GPL(start_poll_synchronize_rcu);
  *
  * Yes, this function does not take counter wrap into account.
  * But counter wrap is harmless.  If the counter wraps, we have waited for
- * more than 2 billion grace periods (and way more on a 64-bit system!).
+ * more than a billion grace periods (and way more on a 64-bit system!).
  * Those needing to keep oldstate values for very long time periods
  * (many hours even on 32-bit systems) should check them occasionally
  * and either refresh them or set a flag indicating that the grace period
@@ -3924,7 +3924,7 @@ EXPORT_SYMBOL_GPL(start_poll_synchronize_rcu);
  */
 bool poll_state_synchronize_rcu(unsigned long oldstate)
 {
-	if (rcu_seq_done(&rcu_state.gp_seq, oldstate)) {
+	if (rcu_seq_done_exact(&rcu_state.gp_seq, oldstate)) {
 		smp_mb(); /* Ensure GP ends before subsequent accesses. */
 		return true;
 	}
-- 
2.31.1.189.g2e36527f23


  reply	other threads:[~2022-06-20 22:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-20 22:49 [PATCH rcu 0/12] Polled grace-period updates for v5.20 Paul E. McKenney
2022-06-20 22:51 ` Paul E. McKenney [this message]
2022-06-20 22:51 ` [PATCH rcu 02/12] rcu: Provide a get_completed_synchronize_rcu() function Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 03/12] rcutorture: Validate get_completed_synchronize_rcu() Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 04/12] rcu: Switch polled grace-period APIs to ->gp_seq_polled Paul E. McKenney
2022-07-21  0:53   ` Boqun Feng
2022-07-21  1:04     ` Paul E. McKenney
2022-07-21  1:51       ` Boqun Feng
2022-07-21  4:47         ` Paul E. McKenney
2022-07-21  5:49           ` Boqun Feng
2022-07-22  1:03             ` Paul E. McKenney
2022-07-21  1:56       ` Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 05/12] rcu: Make polled grace-period API account for expedited grace periods Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 06/12] rcu: Make Tiny RCU grace periods visible to polled APIs Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 07/12] rcutorture: Verify that polled GP API sees synchronous grace periods Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 08/12] rcu: Add polled expedited grace-period primitives Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 09/12] rcutorture: Test " Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 10/12] rcu: Put panic_on_rcu_stall() after expedited RCU CPU stall warnings Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 11/12] rcu: Diagnose extended sync_rcu_do_polled_gp() loops Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 12/12] rcu: Add irqs-disabled indicator to expedited RCU CPU stall warnings 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=20220620225128.3842050-1-paulmck@kernel.org \
    --to=paulmck@kernel.org \
    --cc=bfoster@redhat.com \
    --cc=david@fromorbit.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raven@themaw.net \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=viro@zeniv.linux.org.uk \
    /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