Re: lockmeter

From: Ingo Molnar
Date: Sun Jan 28 2007 - 16:19:06 EST



* Bill Huey <billh@xxxxxxxxxxxxxxxxx> wrote:

> My lock stat stuff shows dcache to a be a problem under -rt as well.
> It is keyed off the same mechanism as lockdep. [...]

btw., while my plan is to prototype your lock-stat patch in -rt
initially, it should be doable to extend it to be usable with the
upstream kernel as well.

We can gather lock contention events when there is spinlock debugging
enabled, from lib/spinlock_debug.c. For example __spin_lock_debug() does
this:

static void __spin_lock_debug(spinlock_t *lock)
{
...
for (i = 0; i < loops; i++) {
if (__raw_spin_trylock(&lock->raw_lock))
return;
__delay(1);
}

where the __delay(1) call is done do we notice contention - and there
you could drive the lock-stat code. Similarly, rwlocks have such natural
points too where you could insert a lock-stat callback without impacting
performance (or the code) all that much. mutexes and rwsems have natural
contention points too (kernel/mutex.c:__mutex_lock_slowpath() and
kernel/rwsem.c:rwsem_down_failed_common()), even with mutex debugging is
off.

for -rt the natural point to gather contention events is in
kernel/rtmutex.c, as you are doing it currently.

finally, you can enable lockdep's initialization/etc. wrappers so that
infrastructure between lockdep and lock-stat is shared, but you dont
have to call into the lock-tracking code of lockdep.c if LOCK_STAT is
enabled and PROVE_LOCKING is disabled. That should give you the lockdep
infrastructure for LOCK_STAT, without the lockdep overhead.

all in one, one motivation behind my interest in your patch for -rt is
that i think it's useful for upstream too, and that it can merge with
lockdep to a fair degree.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/