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

[Paul E. McKenney]

On Mon, Jul 20, 2026 at 04:22:33PM +0200, Frederic Weisbecker wrote:
> Le Tue, Jul 14, 2026 at 11:48:08AM -0700, Paul E. McKenney a écrit :
> > > I have similar concerns about the three smp_mb() in
> > > get_state_synchronize_rcu_full(). It could be just two (rcu_seq_snap()
> > > has a barrier that could be just one). Not sure if that matters but,
> > > just wanted to point that.
> > 
> > We need the one at the beginning of get_state_synchronize_rcu_full(),
> > but from what I can see, not the ones in the calls to rcu_seq_snap().
> > I blame laziness.  We could make an rcu_seq_snap_no_ordering() that
> > didn't have the smp_mb(), but I didn't believe that the overhead would
> > be visible at the system level.
> 
> It isn't so much about performance than being clear about ordering
> expectations. Though we could argue that grace period polling can be
> about performance.
> 
> But in general rcu_seq_snap() advertizes:
> 
>    READ seq
>    smp_mb() /* Above access must not bleed into critical section. */
> 
> This doesn't tell much. Which critical section? That's not used on
> read side.

Fair question!

And the answer is "any critical section that might later be executed by
the current task."

Would it help if I made that comment read as follows, separately from
Puranjay's series?

	// The above access must not bleed into any later RCU read-side
	// critical section executed by the current task.

							Thanx, Paul