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() ?
thanks,
- Joel
