From: Frederic Weisbecker <frederic@kernel.org>
To: Neeraj upadhyay <neeraj.iitr10@gmail.com>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com, rostedt@goodmis.org
Subject: Re: [PATCH rcu 3/6] rcu/exp: Remove superfluous full memory barrier upon first EQS snapshot
Date: Thu, 27 Jun 2024 00:12:48 +0200 [thread overview]
Message-ID: <ZnySYEWMJpcfkmOr@pavilion.home> (raw)
In-Reply-To: <CAFwiDX8OE74e4ZVsy3wJbX5F4Huv0NR1w2EqM4xfeoa03JjCpg@mail.gmail.com>
Le Wed, Jun 26, 2024 at 10:49:58PM +0530, Neeraj upadhyay a écrit :
> On Wed, Jun 26, 2024 at 7:58 PM Frederic Weisbecker <frederic@kernel.org> wrote:
> >
> > Le Wed, Jun 12, 2024 at 02:14:14PM +0530, Neeraj upadhyay a écrit :
> > > On Wed, Jun 5, 2024 at 3:58 AM Paul E. McKenney <paulmck@kernel.org> wrote:
> > > >
> > > > 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>
> > > > ---
> > > > kernel/rcu/tree_exp.h | 8 +++++++-
> > > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
> > > > index 8a1d9c8bd9f74..bec24ea6777e8 100644
> > > > --- a/kernel/rcu/tree_exp.h
> > > > +++ b/kernel/rcu/tree_exp.h
> > > > @@ -357,7 +357,13 @@ static void __sync_rcu_exp_select_node_cpus(struct rcu_exp_work *rewp)
> > > > !(rnp->qsmaskinitnext & mask)) {
> > > > mask_ofl_test |= mask;
> > > > } else {
> > > > - snap = rcu_dynticks_snap(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().
> > >
> > > Again, worth mentioning the chaining sites sync_exp_reset_tree() and
> > > this function?
> >
> > How about this?
> >
>
> Looks good to me, thanks!
And similar to the previous one, a last minute edition:
/*
* Full ordering between remote CPU's post idle accesses
* and updater's accesses prior to current GP (and also
* the started GP sequence number) is enforced by
* rcu_seq_start() implicit barrier, relayed by kworkers
* locking and even further by smp_mb__after_unlock_lock()
* barriers chained all the way throughout the rnp locking
* tree since sync_exp_reset_tree() and up to the current
* leaf rnp locking.
*
* Ordering between remote CPU's pre idle accesses and
* post grace period updater's accesses is enforced by the
* below acquire semantic.
*/
Still ok?
Thanks.
next prev parent reply other threads:[~2024-06-26 22:12 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 ` [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 [this message]
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=ZnySYEWMJpcfkmOr@pavilion.home \
--to=frederic@kernel.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neeraj.iitr10@gmail.com \
--cc=paulmck@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 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.