All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: "Paul E . McKenney" <paulmck@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	rcu <rcu@vger.kernel.org>, Uladzislau Rezki <urezki@gmail.com>,
	Neeraj Upadhyay <quic_neeraju@quicinc.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Joel Fernandes <joel@joelfernandes.org>
Subject: [PATCH 04/10] rcu/nocb: Remove needless full barrier after callback advancing
Date: Fri,  8 Sep 2023 22:35:57 +0200	[thread overview]
Message-ID: <20230908203603.5865-5-frederic@kernel.org> (raw)
In-Reply-To: <20230908203603.5865-1-frederic@kernel.org>

A full barrier is issued from nocb_gp_wait() upon callbacks advancing
to order grace period completion with callbacks execution.

However these two events are already ordered by the
smp_mb__after_unlock_lock() barrier within the call to
raw_spin_lock_rcu_node() that is necessary for callbacks advancing to
happen.

The following litmus test shows the kind of guarantee that this barrier
provides:

	C smp_mb__after_unlock_lock

	{}

	// rcu_gp_cleanup()
	P0(spinlock_t *rnp_lock, int *gpnum)
	{
		// Grace period cleanup increase gp sequence number
		spin_lock(rnp_lock);
		WRITE_ONCE(*gpnum, 1);
		spin_unlock(rnp_lock);
	}

	// nocb_gp_wait()
	P1(spinlock_t *rnp_lock, spinlock_t *nocb_lock, int *gpnum, int *cb_ready)
	{
		int r1;

		// Call rcu_advance_cbs() from nocb_gp_wait()
		spin_lock(nocb_lock);
		spin_lock(rnp_lock);
		smp_mb__after_unlock_lock();
		r1 = READ_ONCE(*gpnum);
		WRITE_ONCE(*cb_ready, 1);
		spin_unlock(rnp_lock);
		spin_unlock(nocb_lock);
	}

	// nocb_cb_wait()
	P2(spinlock_t *nocb_lock, int *cb_ready, int *cb_executed)
	{
		int r2;

		// rcu_do_batch() -> rcu_segcblist_extract_done_cbs()
		spin_lock(nocb_lock);
		r2 = READ_ONCE(*cb_ready);
		spin_unlock(nocb_lock);

		// Actual callback execution
		WRITE_ONCE(*cb_executed, 1);
	}

	P3(int *cb_executed, int *gpnum)
	{
		int r3;

		WRITE_ONCE(*cb_executed, 2);
		smp_mb();
		r3 = READ_ONCE(*gpnum);
	}

	exists (1:r1=1 /\ 2:r2=1 /\ cb_executed=2 /\ 3:r3=0) (* Bad outcome. *)

Here the bad outcome only occurs if the smp_mb__after_unlock_lock() is
removed. This barrier orders the grace period completion against
callbacks advancing and even later callbacks invocation, thanks to the
opportunistic propagation via the ->nocb_lock to nocb_cb_wait().

Therefore the smp_mb() placed after callbacks advancing can be safely
removed.

Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
 kernel/rcu/tree_nocb.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/rcu/tree_nocb.h b/kernel/rcu/tree_nocb.h
index 6e63ba4788e1..2dc76f5e6e78 100644
--- a/kernel/rcu/tree_nocb.h
+++ b/kernel/rcu/tree_nocb.h
@@ -779,7 +779,6 @@ static void nocb_gp_wait(struct rcu_data *my_rdp)
 		if (rcu_segcblist_ready_cbs(&rdp->cblist)) {
 			needwake = rdp->nocb_cb_sleep;
 			WRITE_ONCE(rdp->nocb_cb_sleep, false);
-			smp_mb(); /* CB invocation -after- GP end. */
 		} else {
 			needwake = false;
 		}
-- 
2.41.0


  parent reply	other threads:[~2023-09-08 20:36 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-08 20:35 [PATCH 00/10] rcu cleanups Frederic Weisbecker
2023-09-08 20:35 ` [PATCH 01/10] rcu: Use rcu_segcblist_segempty() instead of open coding it Frederic Weisbecker
2023-10-02 15:38   ` Paul E. McKenney
2023-09-08 20:35 ` [PATCH 02/10] rcu: Rename jiffies_till_flush to jiffies_lazy_flush Frederic Weisbecker
2023-09-09  1:07   ` Joel Fernandes
2023-09-10 19:48     ` Frederic Weisbecker
2023-09-08 20:35 ` [PATCH 03/10] rcu/nocb: Remove needless LOAD-ACQUIRE Frederic Weisbecker
2023-09-09  1:48   ` Joel Fernandes
2023-09-09  1:50     ` Joel Fernandes
2023-09-10 21:17     ` Frederic Weisbecker
2023-09-08 20:35 ` Frederic Weisbecker [this message]
2023-09-09  4:31   ` [PATCH 04/10] rcu/nocb: Remove needless full barrier after callback advancing Joel Fernandes
2023-09-09 18:22     ` Boqun Feng
2023-09-10  4:09       ` Joel Fernandes
2023-09-10 10:22         ` Paul E. McKenney
2023-09-10 20:17         ` Frederic Weisbecker
2023-09-10 20:29           ` Frederic Weisbecker
2023-09-08 20:35 ` [PATCH 05/10] rcu: Assume IRQS disabled from rcu_report_dead() Frederic Weisbecker
2023-10-02 15:41   ` Paul E. McKenney
2023-09-08 20:35 ` [PATCH 06/10] rcu: Assume rcu_report_dead() is always called locally Frederic Weisbecker
2023-10-02 15:45   ` Paul E. McKenney
2023-09-08 20:36 ` [PATCH 07/10] rcu: Conditionally build CPU-hotplug teardown callbacks Frederic Weisbecker
2023-10-04 16:57   ` Paul E. McKenney
2023-09-08 20:36 ` [PATCH 08/10] rcu: Standardize explicit CPU-hotplug calls Frederic Weisbecker
2023-10-02 15:47   ` Paul E. McKenney
2023-09-08 20:36 ` [PATCH 09/10] rcu: Remove references to rcu_migrate_callbacks() from diagrams Frederic Weisbecker
2023-10-02 15:52   ` Paul E. McKenney
2023-09-08 20:36 ` [PATCH 10/10] rcu: Comment why callbacks migration can't wait for CPUHP_RCUTREE_PREP Frederic Weisbecker
2023-10-02 15:48   ` 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=20230908203603.5865-5-frederic@kernel.org \
    --to=frederic@kernel.org \
    --cc=boqun.feng@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=quic_neeraju@quicinc.com \
    --cc=rcu@vger.kernel.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.