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 1/6] rcu: Remove full ordering on second EQS snapshot
Date: Tue, 4 Jun 2024 15:26:47 -0700 [thread overview]
Message-ID: <20240604222652.2370998-1-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. Also the GP kthread must
observe all accesses performed by the target prior it entering in
EQS.
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. Also the GP kthread later
observing that EQS must also observe all accesses performed by the
target prior it entering in EQS.
This ordering is explicitly performed both on the first EQS snapshot
and on the second one as well through the combination of a preceding
full barrier followed by an acquire read. However the second snapshot's
full memory barrier is redundant and not needed to enforce the above
guarantees:
GP kthread Remote target
---- -----
// Access prior GP
WRITE_ONCE(A, 1)
// first snapshot
smp_mb()
x = smp_load_acquire(EQS)
// Access prior GP
WRITE_ONCE(B, 1)
// EQS enter
// implied full barrier by atomic_add_return()
atomic_add_return(RCU_DYNTICKS_IDX, EQS)
// implied full barrier by atomic_add_return()
READ_ONCE(A)
// second snapshot
y = smp_load_acquire(EQS)
z = READ_ONCE(B)
If the GP kthread above fails to observe the remote target in EQS
(x not in EQS), the remote target will observe A == 1 after further
entering in EQS. Then the second snapshot taken by the GP kthread only
need to be an acquire read in order to observe z == 1.
Therefore remove the needless full memory barrier on second snapshot.
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
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 28c7031711a3f..f07b8bff4621b 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -321,7 +321,7 @@ static bool rcu_dynticks_in_eqs(int snap)
*/
static bool rcu_dynticks_in_eqs_since(struct rcu_data *rdp, int snap)
{
- return snap != rcu_dynticks_snap(rdp->cpu);
+ return snap != ct_dynticks_cpu_acquire(rdp->cpu);
}
/*
--
2.40.1
next prev 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 ` Paul E. McKenney [this message]
2024-06-05 12:21 ` [PATCH rcu 1/6] rcu: Remove full ordering on second EQS snapshot 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 ` [PATCH rcu 2/6] rcu: Remove superfluous full memory barrier upon first " Paul E. McKenney
2024-06-12 8:27 ` 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-1-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