Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 6 Mar 2018 13:06:24 -0800
From:   "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To:     Ingo Molnar <mingo@kernel.org>
Cc:     "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
Reply-To: paulmck@linux.vnet.ibm.com
References: <CAOS58YPzLeiZnwEeN31wWMZhki0t9+3ozdRNv9DgxWKY7OKmGA@mail.gmail.com>
 <CA+55aFx48U4W5tUgqW9ioZOHibPhQoDCUDWF_d-7yNCbqFQ7zg@mail.gmail.com>
 <20180305001600.GO3918@linux.vnet.ibm.com>
 <CA+55aFyOi1XnSqHtg=VfcUiBL+egNL==NRX1Zaeihe8W5OJVgw@mail.gmail.com>
 <20180305030949.GP3918@linux.vnet.ibm.com>
 <20180305082441.4hao2z4dqn2n5on6@gmail.com>
 <87po4izj67.fsf_-_@xmission.com>
 <20180305161446.GQ3918@linux.vnet.ibm.com>
 <20180306084738.tcs4ggbby77phlbh@gmail.com>
 <20180306090050.zslv7g37dh6a5kpz@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180306090050.zslv7g37dh6a5kpz@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-Id: <20180306210624.GB3918@linux.vnet.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Mar 06, 2018 at 10:00:50AM +0100, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@kernel.org> wrote:
> 
> >    I.e. the new RCU namespace would be something like:
> > 
> >      call_rcu                     => rcu_call_rcu
> 
> typo: rcu_call().
> 
> >      synchronize_rcu              => rcu_wait_
> 
> typo: rcu_wait().
> 
> Here's the updated table:
> 
>      # RCU APIs:
> 
>      rcu_read_lock                => rcu_read_lock        # unchanged
>      rcu_read_unlock              => rcu_read_unlock      # unchanged
> 
>      call_rcu                     => rcu_call
>      call_rcu_bh                  => rcu_call_bh
>      call_rcu_sched               => rcu_call_sched

	call_rcu_tasks			=> rcu_call_tasks ?

>      synchronize_rcu              => rcu_wait
>      synchronize_rcu_bh           => rcu_wait_bh
>      synchronize_rcu_bh_expedited => rcu_wait_expedited_bh
>      synchronize_rcu_expedited    => rcu_wait_expedited
>      synchronize_rcu_mult         => rcu_wait_mult

The consolidation of RCU, RCU-bh, and RCU-sched would eliminate the
only use of synchronize_rcu_mult().  Should we simply remove it?

>      synchronize_rcu_sched        => rcu_wait_sched
>      synchronize_rcu_tasks        => rcu_wait_tasks
> 
>      get_state_synchronize_rcu    => rcu_get_state
>      cond_synchronize_rcu         => rcu_wait_state

All of rcu_barrier, rcu_barrier_bh, rcu_barrier_sched, rcu_barrier_tasks,
and srcu_barrier remain unchanged, correct?

>      # SRCU APIs:
> 
>      srcu_read_lock               => srcu_read_lock       # unchanged
>      srcu_read_unlock             => srcu_read_unlock     # unchanged
> 
>      synchronize_srcu             => srcu_wait
>      synchronize_srcu_expedited   => srcu_wait_expedited

	call_srcu			=> srcu_call ?

And rcu_assign_pointer, rcu_access_pointer(), and rcu_dereference*()
remain unchanged, correct?  I wouldn't expect RCU's list API to change,
but if we are going to change something, this would be the time...  

On the other hand, the ones you list above are the ones that get used,
hence the ones for which the names are most important.  That said...

The following list is a bit out of date, but is not too far off:

	https://lwn.net/Articles/609973/

Yeah, I know, causing trouble for myself.  ;-)

							Thanx, Paul