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

From: Puranjay Mohan

Date: Sat Jul 25 2026 - 08:05:37 EST


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.

Thanks,
Puranjay