Re: New diagnostic routine - mutex_ownable()

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Mon, 1 May 2017 04:58:52 +0800 (+08)
> From: Paul Goyette <paul%whooppee.com@localhost>
> 
> >> Date: Sun, 30 Apr 2017 13:36:12 +0000 (UTC)
> >> From: christos%astron.com@localhost (Christos Zoulas)
> >>
> >> How frequently is this going to be used and what is the performance
> >> penalty for it. I am asking because I am running LOCKDEBUG all the time.
> 
> 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).