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@meta.com,
	rostedt@goodmis.org, Frederic Weisbecker <frederic@kernel.org>,
	"Paul E . McKenney" <paulmck@kernel.org>
Subject: [PATCH rcu 2/6] rcu: Remove superfluous full memory barrier upon first EQS snapshot
Date: Tue,  4 Jun 2024 15:26:48 -0700	[thread overview]
Message-ID: <20240604222652.2370998-2-paulmck@kernel.org> (raw)
In-Reply-To: <81f4e616-8125-4934-a8e2-fd5beae90995@paulmck-laptop>

From: Frederic Weisbecker <frederic@kernel.org>

When the grace period kthread checks the extended quiescent state
counter of a CPU, full ordering is necessary to ensure that either:

* If the GP kthread observes the remote target in an extended quiescent
  state, then that target must observe all accesses prior to the current
  grace period, including the current grace period sequence number, once
  it exits that extended quiescent state.

or:

* If the GP kthread observes the remote target NOT in an extended
  quiescent state, then the target further entering in an extended
  quiescent state must observe all accesses prior to the current
  grace period, including the current grace period sequence number, once
  it enters that extended quiescent state.

This ordering is enforced through a full memory barrier placed right
before taking the first EQS snapshot. However this is superfluous
because the snapshot is taken while holding the target's rnp lock which
provides the necessary ordering through its chain of
smp_mb__after_unlock_lock().

Remove the needless explicit barrier before the snapshot and put a
comment about the implicit barrier newly relied upon here.

Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
---
 .../Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst    | 6 +++---
 kernel/rcu/tree.c                                          | 7 ++++++-
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
index 5750f125361b0..728b1e690c646 100644
--- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
+++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
@@ -149,9 +149,9 @@ This case is handled by calls to the strongly ordered
 ``atomic_add_return()`` read-modify-write atomic operation that
 is invoked within ``rcu_dynticks_eqs_enter()`` at idle-entry
 time and within ``rcu_dynticks_eqs_exit()`` at idle-exit time.
-The grace-period kthread invokes ``rcu_dynticks_snap()`` and
-``rcu_dynticks_in_eqs_since()`` (both of which invoke
-an ``atomic_add_return()`` of zero) to detect idle CPUs.
+The grace-period kthread invokes first ``ct_dynticks_cpu_acquire()``
+(preceded by a full memory barrier) and ``rcu_dynticks_in_eqs_since()``
+(both of which rely on acquire semantics) to detect idle CPUs.
 
 +-----------------------------------------------------------------------+
 | **Quick Quiz**:                                                       |
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index f07b8bff4621b..1a6ef9c5c949e 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -769,7 +769,12 @@ static void rcu_gpnum_ovf(struct rcu_node *rnp, struct rcu_data *rdp)
  */
 static int dyntick_save_progress_counter(struct rcu_data *rdp)
 {
-	rdp->dynticks_snap = rcu_dynticks_snap(rdp->cpu);
+	/*
+	 * Full ordering against accesses prior current GP and also against
+	 * current GP sequence number is enforced by current rnp locking
+	 * with chained smp_mb__after_unlock_lock().
+	 */
+	rdp->dynticks_snap = ct_dynticks_cpu_acquire(rdp->cpu);
 	if (rcu_dynticks_in_eqs(rdp->dynticks_snap)) {
 		trace_rcu_fqs(rcu_state.name, rdp->gp_seq, rdp->cpu, TPS("dti"));
 		rcu_gpnum_ovf(rdp->mynode, rdp);
-- 
2.40.1


  parent reply	other threads:[~2024-06-04 22:26 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-04 22:26 [PATCH rcu 0/6] Grace-period memory-barrier adjustments for v6.11 Paul E. McKenney
2024-06-04 22:26 ` [PATCH rcu 1/6] rcu: Remove full ordering on second EQS snapshot Paul E. McKenney
2024-06-05 12:21   ` Frederic Weisbecker
2024-06-05 18:44     ` Paul E. McKenney
2024-06-26 15:03       ` Frederic Weisbecker
2024-06-26 15:32         ` Paul E. McKenney
2024-06-26 15:44           ` Frederic Weisbecker
2024-06-27 11:27   ` [PATCH rcu 1/6 v2] " Frederic Weisbecker
2024-06-04 22:26 ` Paul E. McKenney [this message]
2024-06-12  8:27   ` [PATCH rcu 2/6] rcu: Remove superfluous full memory barrier upon first " Neeraj upadhyay
2024-06-26 14:13     ` Frederic Weisbecker
2024-06-26 17:19       ` Neeraj upadhyay
2024-06-26 22:03         ` Frederic Weisbecker
2024-06-27  2:16           ` Neeraj upadhyay
2024-06-27  2:40             ` Neeraj upadhyay
2024-06-27 11:11               ` Frederic Weisbecker
2024-06-27 11:32   ` [PATCH rcu 2/6 v2] " Frederic Weisbecker
2024-06-04 22:26 ` [PATCH rcu 3/6] rcu/exp: " Paul E. McKenney
2024-06-12  8:44   ` Neeraj upadhyay
2024-06-12 14:45     ` Paul E. McKenney
2024-06-26 14:28     ` Frederic Weisbecker
2024-06-26 17:19       ` Neeraj upadhyay
2024-06-26 22:12         ` Frederic Weisbecker
2024-06-27  2:33           ` Neeraj upadhyay
2024-06-27 11:36   ` [PATCH rcu 3/6 v2] " Frederic Weisbecker
2024-06-27 18:53     ` Paul E. McKenney
2024-06-28 11:20       ` Frederic Weisbecker
2024-06-28 20:03         ` Paul E. McKenney
2024-06-04 22:26 ` [PATCH rcu 4/6] rcu: Remove full memory barrier on boot time eqs sanity check Paul E. McKenney
2024-06-04 22:26 ` [PATCH rcu 5/6] rcu: Remove full memory barrier on RCU stall printout Paul E. McKenney
2024-06-04 22:26 ` [PATCH rcu 6/6] rcu/exp: Remove redundant full memory barrier at the end of GP Paul E. McKenney
2024-06-12  5:21 ` [PATCH rcu 0/6] Grace-period memory-barrier adjustments for v6.11 Boqun Feng
2024-06-12  9:42 ` Neeraj Upadhyay
2024-06-12 14:46   ` 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=20240604222652.2370998-2-paulmck@kernel.org \
    --to=paulmck@kernel.org \
    --cc=frederic@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /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