On Mon, 1 May 2017, Paul Goyette wrote:
On Sun, 30 Apr 2017, Taylor R Campbell wrote: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.The idea is that it will be used unconditionally before potentially low-probability conditional branches that acquire the lock. So it may be appropriate to limit its use to KDASSERT, since it means no-lock fast paths don't get to be no-lock fast paths.The only place it is currently planned to be used is in the new localcount(9) code. For each call to device_lookup_acquire(), there would be one corresponding call to device_release(), and that's where this would be used. So, for frequency of use, once for each time a driver looks up the device_t.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, the test would occur for every {b,c}devsw_lookup_acquire() call as well, so the frequency would be fairly often. Still, the cost per invocation would be expected to be quite low.
+------------------+--------------------------+----------------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +------------------+--------------------------+----------------------------+