On Thu, Sep 25, 2025 at 11:40:54AM -0700, Andrii Nakryiko wrote:
> On Tue, Sep 23, 2025 at 7:21 AM Paul E. McKenney <paul...@kernel.org> wrote:
> >
> > This commit updates the documentation to declare that RCU Tasks Trace
> > is implemented as a thin wrapper around SRCU-fast.
> >
> > Signed-off-by: Paul E. McKenney <paul...@kernel.org>
> > Cc: Andrii Nakryiko <and...@kernel.org>
> > Cc: Alexei Starovoitov <a...@kernel.org>
> > Cc: Peter Zijlstra <pet...@infradead.org>
> > Cc: <b...@vger.kernel.org>
> > ---
> > .../RCU/Design/Requirements/Requirements.rst | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst
> > b/Documentation/RCU/Design/Requirements/Requirements.rst
> > index f24b3c0b9b0dc6..4a116d7a564edc 100644
> > --- a/Documentation/RCU/Design/Requirements/Requirements.rst
> > +++ b/Documentation/RCU/Design/Requirements/Requirements.rst
> > @@ -2779,12 +2779,12 @@ 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.
> > +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 API implemented as thin wrappers around SRCU-fast,
> > +which avoids the read-side memory barriers, at least for architectures
> > +that apply noinstr to kernel entry/exit code (or that build with
> > +``CONFIG_TASKS_TRACE_RCU_NO_MB=y``.
>
> For my own education (and due to laziness to try to figure this out on
> my own), what's the situation where you'd want to stick to the
> old-school "heavy-weight" SRCU vs SRCU-fast variant?
There are a couple of use cases for old-school non-fast SRCU: (1) You need
to use srcu_read_lock() where RCU is not watching, and/or (2) you cannot
tolerate the latency of a pair of synchronize_rcu() calls and the IPIs
from the synchronize_rcu_expedited() calls in SRCU-fast grace periods.
But who knows? Perhaps in time everyone will switch to SRCU-fast.
Thanx, Paul
> > The tasks-trace-RCU API is also reasonably compact,
> > consisting of rcu_read_lock_trace(), rcu_read_unlock_trace(),
> > --
> > 2.40.1
> >
