Messages in this thread | | | Date | Sun, 28 Jan 2007 22:17:05 +0100 | From | Ingo Molnar <> | Subject | Re: lockmeter |
| |
* Bill Huey <billh@gnuppy.monkey.org> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |