Re: [PATCH rcu 1/2] docs: Add documentation for rude and trace RCU flavors

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 20 Apr 2022 09:13:19 -0700
"Paul E. McKenney" <paulmck@kernel.org> wrote:

> > > +The tasks-rude-RCU API is also reader-marking-free and thus quite compact,
> > > +consisting of call_rcu_tasks_rude(), synchronize_rcu_tasks_rude(),
> > > +and rcu_barrier_tasks_rude().  
> > 
> > Are we going to be able to get rid of the "rude" version once we have all
> > tracing in a RCU visible section?  
> 
> You tell me!  ;-)
> 
> If there are no longer any users, I would be happy to get rid of it.
> As of v5.18-rc1, the only user is ftrace.
> 
> > > +
> > > +Tasks Trace RCU
> > > +~~~~~~~~~~~~~~~
> > > +
> > > +Some forms of tracing need to sleep in readers, but cannot tolerate
> > > +SRCU's read-side overhead, which includes a full memory barrier in both
> > > +srcu_read_lock() and srcu_read_unlock().  This need is handled by a
> > > +Tasks Trace RCU that uses scheduler locking and IPIs to synchronize with
> > > +readers.  Real-time systems that cannot tolerate IPIs may build their
> > > +kernels with ``CONFIG_TASKS_TRACE_RCU_READ_MB=y``, which avoids the IPIs at
> > > +the expense of adding full memory barriers to the read-side primitives.  
> > 
> > If NOHZ_FULL is enabled, is there a way to also be able to have this full
> > mb on RT removed as well?
> >   

Hmm, if we no longer need the rude version due to noinstr, if then we need
to use something that adds full memory barriers at *every function call*
then I rather keep the rude version.

-- Steve