On Tue, Sep 20, 2022 at 06:40:48PM -0400, Joel Fernandes wrote:
> On Tue, Sep 20, 2022 at 6:35 PM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote:
> >
> > On Tue, Sep 20, 2022 at 06:27:52PM -0400, Joel Fernandes wrote:
> > > On Tue, Sep 20, 2022 at 3:03 PM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote:
> > > [...]
> > > One question - call_rcu_expedited() just means "use regular non lazy
> > > rcu", not "use expedited grace periods" right? In this case, is it
> > > better to call it call_rcu_fast() or call_rcu_nonlazy() to avoid
> > > conflicts with the "expedited" terminology in the
> > > synchronize_{s,}rcu_expedited() APIs?
> >
> > I agree that call_rcu_expedited() is likely to cause confusion.
> > The call_rcu_fast() is nice and short, but the result really is not all
> > that fast. The call_rcu_nonlazy() sounds good, but I am sure that as
> > usual there will be no shortage of bikeshedders. ;-)
>
> call_rcu_tglx() and then we can Thomas's tags :-D Jk.
>
> call_rcu_faster() since it is faster than regular call_rcu()
>
> call_rcu_hurry_up_already() , likely a NAK but sounds cool :-D
>
> Jokes aside,
> call_rcu_flush() - because the CBs are not batched like regular call_rcu() ?
Possibly, possibly...
Thanx, Paul
