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