From: Frederic Weisbecker <frederic@kernel.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com, rostedt@goodmis.org,
Andrii Nakryiko <andrii@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
bpf@vger.kernel.org
Subject: Re: [PATCH v2 14/16] srcu: Create an SRCU-fast-updown API
Date: Wed, 26 Nov 2025 15:06:46 +0100 [thread overview]
Message-ID: <aScJdsi4QNPd-f_2@localhost.localdomain> (raw)
In-Reply-To: <66ee4f2d-9885-446a-996f-801a1fe62a68@paulmck-laptop>
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@kernel.org>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: <bpf@vger.kernel.org>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
--
Frederic Weisbecker
SUSE Labs
next prev parent reply other threads:[~2025-11-26 14:06 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-05 20:31 [PATCH v2 0/16] SRCU updates for v6.19 Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 01/16] srcu: Permit Tiny SRCU srcu_read_unlock() with interrupts disabled Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 02/16] srcu: Create an srcu_expedite_current() function Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 03/16] rcutorture: Test srcu_expedite_current() Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 04/16] srcu: Create a DEFINE_SRCU_FAST() Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 05/16] srcu: Make grace-period determination use ssp->srcu_reader_flavor Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 06/16] rcutorture: Exercise DEFINE_STATIC_SRCU_FAST() and init_srcu_struct_fast() Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 07/16] srcu: Require special srcu_struct define/init for SRCU-fast readers Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 08/16] srcu: Make SRCU-fast readers enforce use of SRCU-fast definition/init Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 09/16] doc: Update for SRCU-fast definitions and initialization Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 10/16] tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast Paul E. McKenney
2025-11-06 16:02 ` Steven Rostedt
2025-11-06 17:01 ` Paul E. McKenney
2025-11-06 17:10 ` Steven Rostedt
2025-11-06 17:52 ` Paul E. McKenney
2025-11-07 0:03 ` Steven Rostedt
2025-11-07 1:04 ` Paul E. McKenney
2025-11-07 1:16 ` Steven Rostedt
2025-11-07 1:53 ` Paul E. McKenney
2025-11-07 12:58 ` Steven Rostedt
2025-11-05 20:32 ` [PATCH v2 11/16] rcu: Mark diagnostic functions as notrace Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 12/16] srcu: Add SRCU_READ_FLAVOR_FAST_UPDOWN CPP macro Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 13/16] torture: Permit negative kvm.sh --kconfig numberic arguments Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 14/16] srcu: Create an SRCU-fast-updown API Paul E. McKenney
2025-11-25 14:18 ` Frederic Weisbecker
2025-11-25 15:54 ` Paul E. McKenney
2025-11-26 14:06 ` Frederic Weisbecker [this message]
2025-11-26 17:09 ` Paul E. McKenney
2025-11-05 20:32 ` [PATCH v2 15/16] srcu: Optimize SRCU-fast-updown for arm64 Paul E. McKenney
2025-11-08 13:07 ` Will Deacon
2025-11-08 18:38 ` Paul E. McKenney
2025-11-10 11:24 ` Will Deacon
2025-11-10 17:29 ` Paul E. McKenney
2025-11-24 13:04 ` Will Deacon
2025-11-24 17:20 ` Paul E. McKenney
2025-11-24 22:47 ` Frederic Weisbecker
2025-11-25 11:40 ` Will Deacon
2025-11-05 20:32 ` [PATCH v2 16/16] rcutorture: Make srcu{,d}_torture_init() announce the SRCU type Paul E. McKenney
2025-11-05 23:00 ` [PATCH v2 0/16] SRCU updates for v6.19 Frederic Weisbecker
2025-11-06 16:06 ` Steven Rostedt
2025-11-07 12:48 ` Frederic Weisbecker
2025-11-07 16:57 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aScJdsi4QNPd-f_2@localhost.localdomain \
--to=frederic@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).