On Tue, Jul 11, 2023 at 09:41:58AM -0700, Paul E. McKenney wrote: > On Tue, Jul 11, 2023 at 06:06:11PM +0200, Frederic Weisbecker wrote: > Heh! > > The purpose was to see if this lock was ever contended. I guess we now > have an answer, which is "Yes, but rarely." > > It looks like the victim commit increased the size of the ->nocb_lock > critical section, just enough to make this happen sometimes. > > Removing the WARN_ON_ONCE() seems appropriate, especially given that > this only happens when shrinking. Ok, I'll check that. > Should we add something that monitors that lock's contention? It is > often the case that lock contention rises over time as new features and > optimizations are added. I'm not sure. Should we keep the current ->nocb_lock_contended based engine to report contention somehow somewhere? Also does it behave better than our current spinlock slow path implementations? Thanks.
