Re: New diagnostic routine - mutex_ownable()

[Chuck Silvers <chuq%chuq.com@localhost>]

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