lkml.org 
[lkml]   [2018]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Simplifying our RCU models
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
>

\
 
 \ /
  Last update: 2018-03-08 22:20    [W:0.064 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site