On Mon, May 01, 2017 at 07:39:55AM +0800, Paul Goyette wrote: > > > As for penalty, it should be very low. The expectation is that there > > > would be no contention for the lock, so no waiting for mutex_enter() to > > > finish. Just the cost of taking and releasing the mutex. > > > > Actually, this can be a high penalty under contention when we could > > have taken a no-lock fast path. > > > > Specifically, any atomic operation, including mutex_enter, requires > > the CPU to send a message to every other CPU on the system bus and > > wait for all the answers to come back. mutex_enter further must wait > > for any active critical section on another CPU to complete. This is > > what a no-lock fast path is supposed to avoid. > > > > Hence I suggest that mutex_ownable be limited to KDASSERT -- so that > > you get it only if you combine DEBUG (expensive consistency checks) > > and LOCKDEBUG (locking bug detection). > > Yes, I agree. I've already made the KDASSERT() change in my local sources.
this is still much more expensive than necessary. it would be easy to add a new lockdebug interface to perform this check rather than using mutex_enter() to get the recursion-check part of lockdebug_wantlock() as a side-effect, so please do that. even when using expensive checks, it's best not to make them more expensive than is really necessary. -Chuck