From: "Paul E. McKenney" <paulmck@kernel.org>
To: Kunwu Chan <kunwu.chan@gmail.com>
Cc: jiangshanlai@gmail.com, josh@joshtriplett.org,
rostedt@goodmis.org, mathieu.desnoyers@efficios.com,
rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH 03/13] srcutree: Add reader-free fastpath to synchronize_srcu_atomic()
Date: Tue, 8 Sep 2026 13:29:04 -0700 [thread overview]
Message-ID: <b7bc58aa-4b8a-4eaa-a7e8-8d338f34d14a@paulmck-laptop> (raw)
In-Reply-To: <20260907075829.2073224-4-kunwu.chan@linux.dev>
On Mon, Sep 07, 2026 at 03:58:19PM +0800, Kunwu Chan wrote:
> From: Kunwu Chan <kunwu.chan@gmail.com>
>
> synchronize_srcu_atomic() is restricted to srcu_read_lock_atomic() and
> srcu_read_unlock_atomic(), whose read-side critical sections disable
> preemption. In the common case where there are no readers at all, the
> grace period therefore need not do the index flip. Add a fastpath
> that sums both ranks of the per-CPU ->srcu_ctrs[] counters and, if the
> lock counts match the unlock counts on both ranks, ends the grace
> period immediately, skipping the srcu_advance_state() scans, mirroring
> the similar Tiny SRCU fastpath.
>
> Correctness requires the counter-sum proof to follow the grace-period
> anchor written by srcu_gp_start(); placing it before the anchor could
> let this grace period miss a pre-existing reader and return without
> waiting for it. The smp_mb() between the unlock and lock sums pairs
> with the smp_mb() in __srcu_read_lock(). The grace period is ended
> manually under ->lock and ->srcu_atomic_gp_flag.
>
> Signed-off-by: Kunwu Chan <kunwu.chan@gmail.com>
Adding David Woodhouse on CC.
David, does this provide appropriate performance in your use case?
Thanx, Paul
> ---
> kernel/rcu/srcutree.c | 48 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index 7dd705eec573..533607de5728 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -2113,6 +2113,8 @@ void synchronize_srcu_atomic(struct srcu_struct *ssp)
> {
> unsigned long srcu_state;
> struct srcu_usage *sup = ssp->srcu_sup;
> + unsigned long rdm0, rdm1;
> + unsigned long unlocks0, unlocks1;
>
> // Initialize. Either init_srcu_struct() was invoked or
> // DEFINE_SRCU() or similar was used. Therefore, no allocation
> @@ -2149,6 +2151,52 @@ void synchronize_srcu_atomic(struct srcu_struct *ssp)
> srcu_gp_start(ssp);
> raw_spin_unlock_irq_rcu_node(sup);
>
> + //
> + // Fastpath: If there are no readers at all, neither grace-period
> + // scan need wait, so both can be satisfied at once without doing
> + // the index flip. The counter-sum proof is the same as that of
> + // srcu_readers_active_idx_check(), but spanning both indices.
> + // Atomic SRCU guarantees that all readers are of
> + // SRCU_READ_FLAVOR_ATOMIC, so the SLOWGP check never triggers and
> + // the ->srcu_reader_flavor masks returned by
> + // srcu_readers_unlock_idx() are unused.
> + //
> + // This proof must follow the grace-period anchor written by the
> + // srcu_gp_start() above, never precede it. With the anchor first,
> + // a reader whose lock increment is missed by the sums below cannot
> + // have incremented its lock counter before the anchor, and therefore
> + // cannot be a pre-existing reader of this grace period. Placing the
> + // proof before the anchor would let this grace period miss a
> + // pre-existing reader and return without waiting for it.
> + //
> + // The smp_mb() pairs with the smp_mb() in __srcu_read_lock()
> + // (store-buffering pattern), which guarantees that a lock is always
> + // counted if the corresponding unlock is counted, the same
> + // memory-ordering guarantee as is provided by
> + // srcu_readers_active_idx_check().
> + //
> + unlocks0 = srcu_readers_unlock_idx(ssp, 0, &rdm0);
> + unlocks1 = srcu_readers_unlock_idx(ssp, 1, &rdm1);
> + smp_mb(); /* A */
> + if (srcu_readers_lock_idx(ssp, 0, false, unlocks0) &&
> + srcu_readers_lock_idx(ssp, 1, false, unlocks1)) {
> + // No readers, so end this grace period manually, skipping
> + // the index flip. Advancing the sequence number via
> + // rcu_seq_start() in srcu_gp_start() above and rcu_seq_end()
> + // below keeps get_state_synchronize_srcu() and
> + // poll_state_synchronize_srcu() working, all under ->lock
> + // and ->srcu_atomic_gp_flag, which excludes concurrent
> + // sequence-number updates.
> + raw_spin_lock_irq_rcu_node(sup);
> + rcu_seq_end(&sup->srcu_gp_seq);
> + raw_spin_unlock_irq_rcu_node(sup);
> + WARN_ON_ONCE(!poll_state_synchronize_srcu(ssp, srcu_state));
> + atomic_set_release(&sup->srcu_atomic_gp_flag, 0);
> + preempt_enable();
> + non_block_end();
> + return;
> + }
> +
> // Wait for it to complete, helping it along.
> while (!poll_state_synchronize_srcu(ssp, srcu_state)) {
> cpu_relax();
> --
> 2.43.0
>
next prev parent reply other threads:[~2026-09-08 20:29 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 7:58 [PATCH 00/13] srcu: Round out atomic SRCU support Kunwu Chan
2026-09-07 7:58 ` [PATCH 01/13] litmus: Add SRCU fastpath anchor-before-scan test Kunwu Chan
2026-09-08 23:58 ` Paul E. McKenney
2026-09-09 3:02 ` Kunwu Chan
2026-09-11 15:51 ` Paul E. McKenney
2026-09-11 16:17 ` KunWu Chan
2026-09-07 7:58 ` [PATCH 02/13] litmus: Add SRCU fastpath scan-before-anchor test Kunwu Chan
2026-09-07 7:58 ` [PATCH 03/13] srcutree: Add reader-free fastpath to synchronize_srcu_atomic() Kunwu Chan
2026-09-08 20:29 ` Paul E. McKenney [this message]
2026-09-08 21:13 ` David Woodhouse
2026-09-08 21:54 ` Paul E. McKenney
2026-09-08 22:09 ` David Woodhouse
2026-09-08 22:55 ` Paul E. McKenney
2026-09-08 22:26 ` David Woodhouse
2026-09-08 22:53 ` Paul E. McKenney
2026-09-08 22:56 ` David Woodhouse
2026-09-08 23:34 ` Paul E. McKenney
2026-09-09 3:35 ` Kunwu Chan
2026-09-07 7:58 ` [PATCH 04/13] rcutorture: Add atomic-SRCU support to torture.sh Kunwu Chan
2026-09-08 23:34 ` Paul E. McKenney
2026-09-09 22:35 ` Paul E. McKenney
2026-09-10 1:30 ` KunWu Chan
2026-09-10 3:47 ` Paul E. McKenney
2026-09-10 4:31 ` KunWu Chan
2026-09-07 7:58 ` [PATCH 05/13] srcutree: Honor is_atomic in check_init_srcu_struct() Kunwu Chan
2026-09-08 20:27 ` Paul E. McKenney
2026-09-07 7:58 ` [PATCH 06/13] srcutree: Make init_srcu_struct_atomic() prevent transition to big Kunwu Chan
2026-09-08 23:36 ` Paul E. McKenney
2026-09-09 2:34 ` Kunwu Chan
2026-09-10 0:08 ` Paul E. McKenney
2026-09-07 7:58 ` [PATCH 07/13] srcutree: Don't transition atomic SRCU to big in srcu_gp_end() Kunwu Chan
2026-09-08 23:38 ` Paul E. McKenney
2026-09-09 2:45 ` Kunwu Chan
2026-09-10 0:13 ` Paul E. McKenney
2026-09-10 3:18 ` KunWu Chan
2026-09-10 3:46 ` Paul E. McKenney
2026-09-10 4:27 ` KunWu Chan
2026-09-07 7:58 ` [PATCH 08/13] srcutree: Forbid srcu_expedite_current() on atomic SRCU Kunwu Chan
2026-09-08 23:43 ` Paul E. McKenney
2026-09-07 7:58 ` [PATCH 09/13] rcutorture: Disable srcu_expedite_current() for " Kunwu Chan
2026-09-08 23:48 ` Paul E. McKenney
2026-09-07 7:58 ` [PATCH 10/13] srcutree: Skip callback scheduling for atomic SRCU grace periods Kunwu Chan
2026-09-09 0:01 ` Paul E. McKenney
2026-09-07 7:58 ` [PATCH 11/13] srcutree: Remove srcu_barrier() sleep for atomic SRCU Kunwu Chan
2026-09-09 0:05 ` Paul E. McKenney
2026-09-07 7:58 ` [PATCH 12/13] srcutree: Remove debug pr_alert()s Kunwu Chan
2026-09-09 0:06 ` Paul E. McKenney
2026-09-07 7:58 ` [PATCH 13/13] srcu: Restrict atomic-SRCU non_block annotation to task context Kunwu Chan
2026-09-09 0:11 ` Paul E. McKenney
2026-09-10 12:16 ` [PATCH 00/13] srcu: Round out atomic SRCU support Zqiang
2026-09-11 2:31 ` KunWu Chan
2026-09-11 9:49 ` KunWu Chan
2026-09-12 0:41 ` Zqiang
2026-09-12 0:58 ` Zqiang
2026-09-12 13:17 ` KunWu Chan
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=b7bc58aa-4b8a-4eaa-a7e8-8d338f34d14a@paulmck-laptop \
--to=paulmck@kernel.org \
--cc=dwmw2@infradead.org \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=kunwu.chan@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--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
all inboxes | Powered by JetHome®