Re: [PATCH v2 6/11] rcu: Enable RCU callbacks to benefit from expedited grace periods

[Paul E. McKenney]

On Sat, Jul 25, 2026 at 01:04:21PM +0100, Puranjay Mohan wrote:
> On Sat, Jul 25, 2026 at 1:23 AM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote:
> >
> > On Fri, Jul 24, 2026 at 11:31:23AM -0700, Puranjay Mohan wrote:
> > > Currently, RCU callbacks only track normal grace-period sequence
> > > numbers.  This means callbacks must wait for normal grace periods to
> > > complete even when expedited grace periods have already elapsed.
> > >
> > > Use the full struct rcu_gp_seq (which tracks both the normal and
> > > expedited grace-period sequences) throughout the callback
> > > infrastructure.
> > >
> > > rcu_segcblist_advance() now checks both normal and expedited GP
> > > completion via poll_state_synchronize_rcu_full(), and becomes
> > > parameterless since it reads the grace-period state internally.
> > > rcu_segcblist_accelerate() stores the full state (both sequences)
> > > instead of just the normal one.  rcu_accelerate_cbs() and
> > > rcu_accelerate_cbs_unlocked() use get_state_synchronize_rcu_full() to
> > > capture both sequences, and the NOCB advance checks use
> > > poll_state_synchronize_rcu_full() instead of comparing only the normal
> > > sequence.
> > >
> > > srcu_segcblist_advance() becomes a standalone implementation because it
> > > compares SRCU sequences directly and cannot use
> > > poll_state_synchronize_rcu_full(), which reads RCU-specific globals.
> > > srcu_segcblist_accelerate() sets the ->exp field to
> > > RCU_GET_STATE_NOT_TRACKED so that poll_state_synchronize_rcu_full()
> > > compares only ->norm and ignores ->exp.
> > >
> > > Signed-off-by: Puranjay Mohan <puranjay@xxxxxxxxxx>
> > > ---
> > > Paul, please take this in place of the original 6/11.  The only change
> > > from v1 is dropping the premature !poll_state_synchronize_rcu_full() gate
> > > in nocb_gp_wait(): if a grace period completed between rcu_advance_cbs()
> > > and that poll, the rcuog slept grace-period-deaf in nocb_gp_sleep() with
> > > advanceable callbacks still queued -- the lost wakeup Frederic diagnosed.
> > > Verified by widening that window with a delay: the original reproduced the
> > > writer stall within ~75s, this version stayed clean.
> >
> > Done, and will test during the weekend, thank you!
> >
> > There were some conflicts, so could you please double-check?
> 
> I have looked at your latest dev branch and everything looks good to me.

Thank you for checking!

And it passed 2400 hours (12 elapsed hours) of testing overnight.

I am calling this good.  ;-)

							Thanx, Paul