On Tue, Sep 08, 2026 at 10:13:39PM +0100, David Woodhouse wrote:
> On Tue, 2026-09-08 at 13:29 -0700, Paul E. McKenney wrote:
> > On Mon, Sep 07, 2026 at 03:58:19PM +0800, Kunwu Chan wrote:
> > > From: Kunwu Chan <[email protected]>
> > >
> > > 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 <[email protected]>
> >
> > Adding David Woodhouse on CC.
> >
> > David, does this provide appropriate performance in your use case?
>
> Looks like it should; I've thrown it into the test. Thanks.
>
> My version¹ didn't drive the GP at all, and just took the fast path if
> there were no readers. And because it didn't drive the GP, I *think*
> the "Correctness requires…" part of the commit message cited above
> didn't apply?
And another option is to pull the fastpath up earlier, before
checking and/or acquiring ->srcu_atomic_gp_flag. But this is a
bit more complicated from a concurrency viewpoint, at least if
we are to interact normally with get_state_synchronize_srcu() and
poll_state_synchronize_srcu(). For example:
srcu_state = get_state_synchronize_srcu(ssp);
synchronize_srcu_atomic(ssp);
WARN_ON_ONCE(!poll_state_synchronize_srcu(ssp, srcu_state));
Without at least some mucking with the grace-period mechanism, that
WARN_ON_ONCE() could trigger, which just might not be universally
considered to be a friendly act. ;-)
So it would be very good to keep the fastpath where Kunwu put it, if
that works reasonably.
> Driving the GP does mean a certain amount of serialization that my
> earlier bailout didn't incur, but I think that's probably only going to
> show up on a microbenchmark. Let's see.
Here is hoping!
> I *do* want the fast path used from synchronize_srcu_expedited()
> though, if possible. That's what solves Sean's *other* problem. Can we
> have that?
I believe so, but let's get this put to bed first. Please note
that synchronize_srcu_expedited() has the same relationship with
get_state_synchronize_srcu() and poll_state_synchronize_srcu(), so there
will be some trickiness there as well.
Thanx, Paul
> ¹ https://git.infradead.org/?p=users/dwmw2/linux.git;a=commitdiff;h=0f1456f508
> https://git.infradead.org/?p=users/dwmw2/linux.git;a=commitdiff;h=62ff5ac4ca
