From: Frederic Weisbecker <frederic@kernel.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@fb.com, mingo@kernel.org, jiangshanlai@gmail.com,
akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org,
rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com,
fweisbec@gmail.com, oleg@redhat.com, joel@joelfernandes.org
Subject: Re: [PATCH tip/core/rcu 2/3] rcu: Provide polling interfaces for Tiny RCU grace periods
Date: Mon, 22 Mar 2021 20:00:35 +0100 [thread overview]
Message-ID: <20210322190035.GA874833@lothringen> (raw)
In-Reply-To: <20210322154744.GM2696@paulmck-ThinkPad-P72>
On Mon, Mar 22, 2021 at 08:47:44AM -0700, Paul E. McKenney wrote:
> On Sun, Mar 21, 2021 at 11:28:55PM +0100, Frederic Weisbecker wrote:
> > On Wed, Mar 03, 2021 at 04:26:31PM -0800, paulmck@kernel.org wrote:
> > > From: "Paul E. McKenney" <paulmck@kernel.org>
> > >
> > > There is a need for a non-blocking polling interface for RCU grace
> > > periods, so this commit supplies start_poll_synchronize_rcu() and
> > > poll_state_synchronize_rcu() for this purpose. Note that the existing
> > > get_state_synchronize_rcu() may be used if future grace periods are
> > > inevitable (perhaps due to a later call_rcu() invocation). The new
> > > start_poll_synchronize_rcu() is to be used if future grace periods
> > > might not otherwise happen. Finally, poll_state_synchronize_rcu()
> > > provides a lockless check for a grace period having elapsed since
> > > the corresponding call to either of the get_state_synchronize_rcu()
> > > or start_poll_synchronize_rcu().
> > >
> > > As with get_state_synchronize_rcu(), the return value from either
> > > get_state_synchronize_rcu() or start_poll_synchronize_rcu() is passed in
> > > to a later call to either poll_state_synchronize_rcu() or the existing
> > > (might_sleep) cond_synchronize_rcu().
> > >
> > > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> > > ---
> > > include/linux/rcutiny.h | 11 ++++++-----
> > > kernel/rcu/tiny.c | 40 ++++++++++++++++++++++++++++++++++++++++
> > > 2 files changed, 46 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> > > index 2a97334..69108cf4 100644
> > > --- a/include/linux/rcutiny.h
> > > +++ b/include/linux/rcutiny.h
> > > @@ -17,14 +17,15 @@
> > > /* Never flag non-existent other CPUs! */
> > > static inline bool rcu_eqs_special_set(int cpu) { return false; }
> > >
> > > -static inline unsigned long get_state_synchronize_rcu(void)
> > > -{
> > > - return 0;
> > > -}
> > > +unsigned long get_state_synchronize_rcu(void);
> > > +unsigned long start_poll_synchronize_rcu(void);
> > > +bool poll_state_synchronize_rcu(unsigned long oldstate);
> > >
> > > static inline void cond_synchronize_rcu(unsigned long oldstate)
> > > {
> > > - might_sleep();
> > > + if (poll_state_synchronize_rcu(oldstate))
> > > + return;
> > > + synchronize_rcu();
> >
> > Perhaps cond_synchronize_rcu() could stay as it was. If it might
> > call synchronize_rcu() then it inherits its constraint to be
> > called from a quiescent state.
>
> As in leave the might_sleep()? How about something like this?
>
> static inline void cond_synchronize_rcu(unsigned long oldstate)
> {
> if (!poll_state_synchronize_rcu(oldstate))
> synchronize_rcu();
> else
> might_sleep();
> }
>
> One advantage of this is that the Tiny and Tree implementations
> become identical and can then be consolidated.
>
> Or did I miss your point?
But poll_state_synchronize_rcu() checks that the gp_num has changed,
which is not needed for cond_synchronize_rcu() since this it is
only allowed to be called from a QS.
>
> Thanx, Paul
next prev parent reply other threads:[~2021-03-22 19:01 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-04 0:26 [PATCH tip/core/rcu 0/3] Polling RCU grace-period interfaces for v5.13 Paul E. McKenney
2021-03-04 0:26 ` [PATCH tip/core/rcu 1/3] rcu: Provide polling interfaces for Tree RCU grace periods paulmck
2021-03-12 12:21 ` Frederic Weisbecker
2021-03-12 12:26 ` Frederic Weisbecker
2021-03-15 23:11 ` Paul E. McKenney
2021-03-16 14:47 ` Frederic Weisbecker
2021-03-16 16:42 ` Paul E. McKenney
2021-03-16 15:17 ` Frederic Weisbecker
2021-03-16 16:51 ` Paul E. McKenney
2021-03-18 14:59 ` Frederic Weisbecker
2021-03-18 17:09 ` Paul E. McKenney
2021-03-19 13:58 ` Frederic Weisbecker
2021-03-19 17:51 ` Paul E. McKenney
2021-03-19 22:10 ` Frederic Weisbecker
2021-03-19 23:38 ` Paul E. McKenney
2021-03-19 23:47 ` Frederic Weisbecker
2021-03-04 0:26 ` [PATCH tip/core/rcu 2/3] rcu: Provide polling interfaces for Tiny " paulmck
2021-03-21 22:28 ` Frederic Weisbecker
2021-03-22 15:47 ` Paul E. McKenney
2021-03-22 19:00 ` Frederic Weisbecker [this message]
2021-03-22 19:45 ` Paul E. McKenney
2021-03-23 14:02 ` Frederic Weisbecker
2021-03-23 16:45 ` Paul E. McKenney
2021-03-04 0:26 ` [PATCH tip/core/rcu 3/3] rcutorture: Test start_poll_synchronize_rcu() and poll_state_synchronize_rcu() paulmck
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=20210322190035.GA874833@lothringen \
--to=frederic@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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.