From: Andrea Parri <parri.andrea@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, Jann Horn <jannh@google.com>,
Benjamin LaHaise <bcrl@kvack.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org
Subject: Re: Simplifying our RCU models
Date: Thu, 8 Mar 2018 22:19:50 +0100 [thread overview]
Message-ID: <20180308211950.GA3202@andrea> (raw)
In-Reply-To: <20180307155444.GA10367@linux.vnet.ibm.com>
On Wed, Mar 07, 2018 at 07:54:44AM -0800, Paul E. McKenney wrote:
> On Tue, Mar 06, 2018 at 12:39:06PM -0800, Paul E. McKenney wrote:
> > On Tue, Mar 06, 2018 at 09:47:38AM +0100, Ingo Molnar wrote:
> > >
> > > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > >
> > > > > > But if we look at the bigger API picture:
> > > > > >
> > > > > > !PREEMPT_RCU PREEMPT_RCU=y
> > > > > > rcu_read_lock(): atomic preemptible
> > > > > > rcu_read_lock_sched(): atomic atomic
> > > > > > srcu_read_lock(): preemptible preemptible
> > > > > >
> > > > > > Then we could maintain full read side API flexibility by making PREEMPT_RCU=y the
> > > > > > only model, merging it with SRCU and using these main read side APIs:
> > > > > >
> > > > > > rcu_read_lock_preempt_disable(): atomic
> > > > > > rcu_read_lock(): preemptible
> > > >
> > > > One issue with merging SRCU into rcu_read_lock() is the general blocking within
> > > > SRCU readers. Once merged in, these guys block everyone. We should focus
> > > > initially on the non-SRCU variants.
> > > >
> > > > On the other hand, Linus's suggestion of merging rcu_read_lock_sched()
> > > > into rcu_read_lock() just might be feasible. If that really does pan
> > > > out, we end up with the following:
> > > >
> > > > !PREEMPT PREEMPT=y
> > > > rcu_read_lock(): atomic preemptible
> > > > srcu_read_lock(): preemptible preemptible
> > > >
> > > > In this model, rcu_read_lock_sched() maps to preempt_disable() and (as
> > > > you say above) rcu_read_lock_bh() maps to local_bh_disable(). The way
> > > > this works is that in PREEMPT=y kernels, synchronize_rcu() waits not
> > > > only for RCU read-side critical sections, but also for regions of code
> > > > with preemption disabled. The main caveat seems to be that there be an
> > > > assumed point of preemptibility between each interrupt and each softirq
> > > > handler, which should be OK.
> > > >
> > > > There will be some adjustments required for lockdep-RCU, but that should
> > > > be reasonably straightforward.
> > > >
> > > > Seem reasonable?
> > >
> > > Yes, that approach sounds very reasonable to me: it is similar to what we do on
> > > the locking side as well, where we have 'atomic' variants (spinlocks/rwlocks) and
> > > 'sleeping' variants (mutexes, rwsems, etc.).
> > >
> > > ( This means there will be more automatic coupling between BH and preempt critical
> > > sections and RCU models not captured via explicit RCU-namespace APIs, but that
> > > should be OK I think. )
> >
> > Thus far, I have been unable to prove that it cannot work, which is about
> > as good as it gets at this stage. So here is hoping! ;-)
> >
> > I will look at your later corrected message, but will gratefully accept
> > your offer of help with the naming transition.
>
> Ah, and any thoughts on how best to get feedback from the various people
> who would need to reprogram their fingers? Or is everyone already on
> board with changing these various names?
Experienced should get there in a week (gcc help); newbies would (have to)
rely on either on _properly updated_ documentation or weeks/months of code
paging; scripts do the renaming. What am I missing?
Andrea
>
> Thanx, Paul
>
next prev parent reply other threads:[~2018-03-08 21:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAG48ez17vOL0oEWqoqdHCjqfGVX+aPhHBrtgCfn35z6jZ=8-Xg@mail.gmail.com>
[not found] ` <CA+55aFzQPQw2UqQ2EEGN1Xe7=qDs-2VTvHVi7SSqGNwqNRg0cQ@mail.gmail.com>
[not found] ` <CAOS58YPzLeiZnwEeN31wWMZhki0t9+3ozdRNv9DgxWKY7OKmGA@mail.gmail.com>
[not found] ` <CA+55aFx48U4W5tUgqW9ioZOHibPhQoDCUDWF_d-7yNCbqFQ7zg@mail.gmail.com>
[not found] ` <20180305001600.GO3918@linux.vnet.ibm.com>
[not found] ` <CA+55aFyOi1XnSqHtg=VfcUiBL+egNL==NRX1Zaeihe8W5OJVgw@mail.gmail.com>
[not found] ` <20180305030949.GP3918@linux.vnet.ibm.com>
[not found] ` <20180305082441.4hao2z4dqn2n5on6@gmail.com>
2018-03-05 14:33 ` Simplifying our RCU models Eric W. Biederman
2018-03-05 16:14 ` Paul E. McKenney
2018-03-06 8:47 ` Ingo Molnar
2018-03-06 9:00 ` Ingo Molnar
2018-03-06 21:06 ` Paul E. McKenney
2018-03-06 20:39 ` Paul E. McKenney
2018-03-07 15:54 ` Paul E. McKenney
2018-03-07 18:48 ` Linus Torvalds
2018-03-08 20:45 ` Paul E. McKenney
2018-04-10 23:44 ` Paul E. McKenney
2018-06-08 16:51 ` Paul E. McKenney
2018-06-27 22:28 ` Paul E. McKenney
2018-08-29 21:47 ` Paul E. McKenney
2018-03-08 21:19 ` Andrea Parri [this message]
[not found] ` <20180309005145.GZ3918@linux.vnet.ibm.com>
[not found] ` <20180309095520.GA5079@andrea>
[not found] ` <20180310160409.GF3918@linux.vnet.ibm.com>
[not found] ` <20180310162946.GA7548@andrea>
[not found] ` <20180310224726.GI3918@linux.vnet.ibm.com>
2018-03-10 23:36 ` Andrea Parri
2018-03-09 9:48 ` Lai Jiangshan
2018-03-10 16:06 ` 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=20180308211950.GA3202@andrea \
--to=parri.andrea@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=bcrl@kvack.org \
--cc=ebiederm@xmission.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).