linux-kernel - Re: lockmeter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070128211705.GA9596@elte.hu>
Date:	Sun, 28 Jan 2007 22:17:05 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Bill Huey <billh@...ppy.monkey.org>
Cc:	"Martin J. Bligh" <mbligh@...igh.org>,
	Christoph Hellwig <hch@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	Dipankar Sarma <dipankar@...l9.org>
Subject: Re: lockmeter

* Bill Huey <billh@...ppy.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/