From: Bill Huey (hui) <billh@gnuppy.monkey.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org, Jason Baron <jbaron@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
"Bill Huey (hui)" <billh@gnuppy.monkey.org>
Subject: Re: [PATCH] lockdep: lock contention tracking
Date: Mon, 21 May 2007 02:18:48 -0700 [thread overview]
Message-ID: <20070521091848.GB4593@gnuppy.monkey.org> (raw)
In-Reply-To: <20070521075013.GA9419@elte.hu>
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
next prev parent reply other threads:[~2007-05-21 9:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-20 10:30 [PATCH] lockdep: lock contention tracking Peter Zijlstra
2007-05-20 18:05 ` Ingo Molnar
2007-05-21 6:04 ` Bill Huey
2007-05-21 6:08 ` Ingo Molnar
2007-05-21 6:41 ` Bill Huey
2007-05-21 7:50 ` Ingo Molnar
2007-05-21 9:18 ` Bill Huey [this message]
2007-05-21 9:36 ` Ingo Molnar
2007-05-21 9:55 ` Christoph Hellwig
2007-05-21 10:21 ` Bill Huey
2007-05-21 10:58 ` Ingo Molnar
2007-05-21 19:17 ` Bill Huey
2007-05-21 10:19 ` Bill Huey
2007-05-21 10:28 ` Bill Huey
2007-05-21 12:46 ` Ingo Molnar
2007-05-21 19:09 ` Bill Huey
2007-05-21 20:58 ` Jason Baron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070521091848.GB4593@gnuppy.monkey.org \
--to=billh@gnuppy.monkey.org \
--cc=a.p.zijlstra@chello.nl \
--cc=jbaron@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.