[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aScJdsi4QNPd-f_2@localhost.localdomain>
Date: Wed, 26 Nov 2025 15:06:46 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
rostedt@...dmis.org, Andrii Nakryiko <andrii@...nel.org>,
Alexei Starovoitov <ast@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, bpf@...r.kernel.org
Subject: Re: [PATCH v2 14/16] srcu: Create an SRCU-fast-updown API
Le Tue, Nov 25, 2025 at 07:54:33AM -0800, Paul E. McKenney a écrit :
> On Tue, Nov 25, 2025 at 03:18:25PM +0100, Frederic Weisbecker wrote:
> > Le Wed, Nov 05, 2025 at 12:32:14PM -0800, Paul E. McKenney a écrit :
> > > This commit creates an SRCU-fast-updown API, including
> > > DEFINE_SRCU_FAST_UPDOWN(), DEFINE_STATIC_SRCU_FAST_UPDOWN(),
> > > __init_srcu_struct_fast_updown(), init_srcu_struct_fast_updown(),
> > > srcu_read_lock_fast_updown(), srcu_read_unlock_fast_updown(),
> > > __srcu_read_lock_fast_updown(), and __srcu_read_unlock_fast_updown().
> > >
> > > These are initially identical to their SRCU-fast counterparts, but both
> > > SRCU-fast and SRCU-fast-updown will be optimized in different directions
> > > by later commits. SRCU-fast will lack any sort of srcu_down_read() and
> > > srcu_up_read() APIs, which will enable extremely efficient NMI safety.
> > > For its part, SRCU-fast-updown will not be NMI safe, which will enable
> > > reasonably efficient implementations of srcu_down_read_fast() and
> > > srcu_up_read_fast().
> >
> > Doing a last round of reviews before sitting down on a pull request,
> > I think the changelog in this one should mention what are the expected
> > uses of SRCU-fast-updown, since the RCU-TASK-TRACE conversion bits aren't
> > there for this merge window yet.
>
> The RCU Tasks Trace conversion is helped by RCU-fast. RCU-fast-updown
> is needed for Andrii's uretprobes code in order to get rid of the
> read-side memory barriers while still allowing entering the reader at
> task level while exiting it in a timer handler.
>
> Does any of that help?
>
> Oh, and commit-by-commit testing passed this past evening, so still
> looking good there!
Ok, here is the new proposed changelog accordingly:
----
srcu: Create an SRCU-fast-updown API
This commit creates an SRCU-fast-updown API, including
DEFINE_SRCU_FAST_UPDOWN(), DEFINE_STATIC_SRCU_FAST_UPDOWN(),
__init_srcu_struct_fast_updown(), init_srcu_struct_fast_updown(),
srcu_read_lock_fast_updown(), srcu_read_unlock_fast_updown(),
__srcu_read_lock_fast_updown(), and __srcu_read_unlock_fast_updown().
These are initially identical to their SRCU-fast counterparts, but both
SRCU-fast and SRCU-fast-updown will be optimized in different directions
by later commits. SRCU-fast will lack any sort of srcu_down_read() and
srcu_up_read() APIs, which will enable extremely efficient NMI safety.
For its part, SRCU-fast-updown will not be NMI safe, which will enable
reasonably efficient implementations of srcu_down_read_fast() and
srcu_up_read_fast().
This API fork happens to meet two different future usecases.
* SRCU-fast will become the reimplementation basis for RCU-TASK-TRACE
for consolidation. Since RCU-TASK-TRACE must be NMI safe, SRCU-fast
must be as well.
* SRCU-fast-updown will be needed for uretprobes code in order to get
rid of the read-side memory barriers while still allowing entering the
reader at task level while exiting it in a timer handler.
This commit also adds rcutorture tests for the new APIs. This
(annoyingly) needs to be in the same commit for bisectability. With this
commit, the 0x8 value tests SRCU-fast-updown. However, most SRCU-fast
testing will be via the RCU Tasks Trace wrappers.
[ paulmck: Apply s/0x8/0x4/ missing change per Boqun Feng feedback. ]
[ paulmck: Apply Akira Yokosawa feedback. ]
Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
Cc: Andrii Nakryiko <andrii@...nel.org>
Cc: Alexei Starovoitov <ast@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: <bpf@...r.kernel.org>
Signed-off-by: Frederic Weisbecker <frederic@...nel.org>
--
Frederic Weisbecker
SUSE Labs
Powered by blists - more mailing lists