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

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 [off-list ref] wrote:

quoted

On Fri, Jul 24, 2026 at 11:31:23AM -0700, Puranjay Mohan wrote:

quoted

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@kernel.org>
---
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