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,
> 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
> >
