On Mon, May 21, 2007 at 09:50:13AM +0200, Ingo Molnar wrote: > Have you looked at the output Peter's patch produces? It prints out > precise symbols: > > dcache_lock: 3000 0 [618] [<ffffffff8033badd>] _atomic_dec_and_lock+0x39/0x58 > > which can easily be turned into line numbers using debuginfo packages or > using gdb. (But normally one only needs the symbol name, and we > certainly do not want to burden the kernel source with tracking > __FILE__/__LINE__ metadata, if the same is already available via > CONFIG_DEBUG_INFO.) > > anything else?
If his hashing scheme can produce precise locations of where locks are initialized both by a initializer function or a statically allocated object then my code is baroque and you should use Peter's code. I write lockstat without the knowledge that lockdep was replicating the same work and I audited 1600 something lock points in the kernel to convert the usage of C99 style initializers to something more regular. I also did this without consideration of things like debuginfo since I don't use those things. > > [...] My stuff is potentially more extensible since I have other ideas > > for it that really are outside of the lockdep logic currently. [...] > > what do you mean, specifically? Better if I show you the patches in the future instead of saying now. > i really need specifics. Currently i have the choice between your stuff: > > 17 files changed, 1425 insertions(+), 80 deletions(-) > > and Peter's patch: > > 6 files changed, 266 insertions(+), 18 deletions(-) > > and Peter's patch (if it works out fine in testing - and it seemed fine > so far on my testbox), is smaller, more maintainable, better integrated > and thus the clear candidate for merging into -rt and merging upstream > as well. It's far cleaner than i hoped this whole lock-stats thing could > be done based on lockdep, so i'm pretty happy with Peter's current patch > already. If it meets your criteria and what you mentioned about is completely accurate, then use it instead of mine. I'll just finish up what I have done with reader tracking in my lockstat and migrate my -rt specific goodies to his infrastructure. bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
