On Wed, Mar 29, 2023 at 01:54:20PM -0700, Paul E. McKenney wrote: > On Wed, Mar 29, 2023 at 06:02:02PM +0200, Frederic Weisbecker wrote: > > The ->lazy_len is only checked locklessly. Recheck again under the > > ->nocb_lock to avoid spending more time on flushing/waking if not > > necessary. The ->lazy_len can still increment concurrently (from 1 to > > infinity) but under the ->nocb_lock we at least know for sure if there > > are lazy callbacks at all (->lazy_len > 0). > > > > Signed-off-by: Frederic Weisbecker <frederic@xxxxxxxxxx> > > --- > > kernel/rcu/tree_nocb.h | 16 ++++++++++++---- > > 1 file changed, 12 insertions(+), 4 deletions(-) > > > > diff --git a/kernel/rcu/tree_nocb.h b/kernel/rcu/tree_nocb.h > > index c321fce2af8e..dfa9c10d6727 100644 > > --- a/kernel/rcu/tree_nocb.h > > +++ b/kernel/rcu/tree_nocb.h > > @@ -1358,12 +1358,20 @@ lazy_rcu_shrink_scan(struct shrinker *shrink, struct shrink_control *sc) > > if (!rcu_rdp_is_offloaded(rdp)) > > continue; > > > > + if (!READ_ONCE(rdp->lazy_len)) > > + continue; > > Do you depend on the ordering of the above read of ->lazy_len against > anything in the following, aside from the re-read of ->lazy_len? (Same > variable, both READ_ONCE() or stronger, so you do get that ordering.) > > If you do need that ordering, the above READ_ONCE() needs to instead > be smp_load_acquire() or similar. If you don't need that ordering, > what you have is good. No ordering dependency intended here. The early ->lazy_len read is really just an optimization here to avoid locking if it *seems* there is nothing to do with this rdp. But what follows doesn't depend on that read. Thanks.
