lkml.org 
[lkml]   [2022]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH rcu 1/2] docs: Add documentation for rude and trace RCU flavors
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

\
 
 \ /
  Last update: 2022-04-20 18:20    [W:0.220 / U:0.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site