On Wed, Aug 26, 2026 at 12:19:58PM +0800, KunWu Chan wrote:
> On Wed, Aug 26, 2026 at 11:53 AM Paul E. McKenney <[email protected]> wrote:
> >
> > On Wed, Aug 26, 2026 at 03:26:18AM +0000, Kunwu Chan wrote:
> > > Hi Paul,
> > >
> > > I'd be interested in helping with one of these. Are there any items
> > > that are not already being worked on and would be useful for me to
> > > take on? I'm particularly interested in the Tree
> > > `synchronize_srcu_atomic()` fastpath, if that part is still open.
> >
> > Please feel free to give it a shot. The similar fastpath in Tiny SRCU
> > is a partial guide. The trick is that get_state_synchronize_srcu()
> > and poll_state_synchronize_srcu() need to keep working.
> >
> > The commit that I just pushed to -rcu on branch "dev" seems to have a
> > working rcutorture. Seems. ;-)
> >
> > Thanx, Paul
>
> Thanks Paul,
>
> I'll start by looking at the Tiny fastpath and how the state-based
> synchronization APIs depend on the SRCU index, then work through
> the corresponding Tree fastpath.
Very good! And please do not forget memory-ordering issues.
Thanx, Paul
> Thanks,
> Kunwu
>
>
> > > Thanks,
> > > Kunwu
> > >
> > >
> > > August 26, 2026 at 7:49 AM, "Paul E. McKenney" <[email protected]
> > > mailto:[email protected]?to=%22Paul%20E.%20McKenney%22%20%3Cpaulmck%40kernel.org%3E
> > > > wrote:
> > >
> > >
> > > >
> > > > On Fri, Aug 21, 2026 at 12:53:22PM +0100, David Woodhouse wrote:
> > > >
> > > > >
> > > > > On Fri, 2026-08-21 at 11:22 +0800, Kunwu Chan wrote:
> > > > >
> > > > [ . . . ]
> > > >
> > > > >
> > > > > When applying this to current rcu/dev, the patch also needs to account
> > > > > for the additional bool is_atomic argument to
> > > > > check_init_srcu_struct(). Please rebase accordingly.
> > > > >
> > > > > Ooh, shiny, I hadn't spotted that the atomic thing had landed. Maybe
> > > > > I
> > > > > should retract my 'if we get that' above... but let's see how it
> > > > > survives.
> > > > >
> > > > It is starting to shape up. Here is what is left, that I know of,
> > > > anyway:
> > > >
> > > > o A bit more work to get rcutorture to put up with atomic SRCU.
> > > >
> > > > o Tree synchronize_srcu_atomic() fastpath.
> > > >
> > > > o Disable preemption.
> > > >
> > > > o Reorganize commits to fix the Tiny hunks that got applied
> > > > in Tree commits, and likely other similar issues.
> > > >
> > > > o More work on error checking for use of banned primitives
> > > > with atomic SRCU.
> > > >
> > > > o Update documentation.
> > > >
> > > > Not that it matters, but atomic Tiny SRCU seems to be doing quite well.
> > > >
> > > > >
> > > > > I also have more than just this patch to rebase onto rcu/dev — unlike
> > > > > some, I'm not just hacking RCU for the fun of it; I get my jollies
> > > > > elsewhere :)
> > > > >
> > > > > Btw, the current commit c68271c3f83a message says "no index flip, no
> > > > > grace-period sequence update" but that isn't true of the
> > > > > implementation
> > > > > any more, is it? In fact, it *always* does those things, and doesn't
> > > > > take the try-path optimisation by counting both epochs, that I'm
> > > > > doing
> > > > > here?
> > > > >
> > > > The current "dev" branch is here:
> > > >
> > > > dc5bf5c8fb26 ("fixup! srcutree: Add an atomic Tree SRCU").
> > > >
> > > > Tree SRCU always does an index flip, though a single index flip can
> > > > serve multiple concurrent calls to synchronze_srcu_atomic().
> > > >
> > > > Tiny SRCU has the fast path, but must advance the index anyway for the
> > > > benefit of get_state_synchronize_srcu() and friends. It just bumps it
> > > > in one shot.
> > > >
> > > > Tree SRCU will also have to bump the index, but will be able to
> > > > do so manually, without doing all the grace-period processing.
> > > >
> > > > >
> > > > > Thanks for the careful review.
> > > > >
> > > > What David said! ;-)
> > > >
> > > > Thanx, Paul
> > > >
