From: "Török Edwin" <edwintorok@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: "Frank Ch. Eigler" <fche@redhat.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
srostedt@redhat.com, sandmann@daimi.au.dk,
linux-kernel@vger.kernel.org, viro@ZenIV.linux.org.uk
Subject: Re: [PATCH 2/2] tracing: identify which executable object the userspace address belongs to
Date: Thu, 27 Nov 2008 16:27:49 +0200 [thread overview]
Message-ID: <492EAE65.1040903@gmail.com> (raw)
In-Reply-To: <20081127141054.GB25657@elte.hu>
On 2008-11-27 16:10, Ingo Molnar wrote:
> Your patches are nice. Right now they are in tracing/core and
> linux-next already.
Thanks. I can move on to the lock latency tracing ;)
I'll send out a draft of tracepoints that I would need to trace lock
latency.
I'll try to put them in same place as lockstat (but not necesarely
depending on lockstat being enabled).
Once we reach a lock-tracepoints patch that all agree upon, I can (try
to) write a ftrace-lock-latency that will have a histogram view
(as you've suggested similar to what the likely/unlikely tracer already
does), but also show separate counts per unique kernel/user stacktrace.
Or I could add the tracepoints inside lockstat (now that it has contend
with points feature), and use the information already gathered by lockstat,
but augment it with finer grained counts per kernel/user stacktrace.
(again there would be an ftrace plugin that would register with the
tracepoints, and show
the per stacktrace statistic in /sys/kernel/debug/tracing/trace).
Which approach should I try first?
Although my goal would be to be able to use this feature by simply
turning on a flag at runtime (whether something in /proc or
/sys/kernel/debug),
rather than rebooting to a different kernel, it may be easier to
implement this at first by using what lockstat already provides, and
later improving it
to work w/o lockstat.
What do you think?
Best regards,
--Edwin
next prev parent reply other threads:[~2008-11-27 14:28 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-22 11:28 [PATCH 0/2] tracing: userspace stacktraces Török Edwin
2008-11-22 11:28 ` [PATCH 1/2] tracing: add support for userspace stacktraces in tracing/iter_ctrl Török Edwin
2008-11-23 8:37 ` Ingo Molnar
2008-11-23 10:39 ` [PATCH 3/3] tracing/stack-tracer: introduce CONFIG_USER_STACKTRACE_SUPPORT Török Edwin
2008-11-22 11:28 ` [PATCH 2/2] tracing: identify which executable object the userspace address belongs to Török Edwin
2008-11-23 8:47 ` [PATCH] vfs, seqfile: make mangle_path() global Ingo Molnar
2008-11-23 21:06 ` Randy Dunlap
2008-11-23 21:24 ` [PATCH] fix comment style on mangle_path Török Edwin
2008-11-23 21:36 ` Ingo Molnar
2008-11-28 10:05 ` [PATCH] vfs, seqfile: make mangle_path() global Al Viro
2008-11-28 17:08 ` Ingo Molnar
2008-11-23 8:53 ` [PATCH 2/2] tracing: identify which executable object the userspace address belongs to Ingo Molnar
2008-11-23 10:39 ` [PATCH 1/3] tracing/stack-tracer: fix style issues Török Edwin
2008-11-23 10:39 ` [PATCH 2/3] tracing/stack-tracer: fix locking Török Edwin
2008-11-23 10:52 ` Ingo Molnar
2008-11-23 10:59 ` Török Edwin
2008-11-23 11:01 ` Ingo Molnar
2008-11-23 11:04 ` Török Edwin
2008-11-23 11:07 ` Ingo Molnar
2008-11-23 11:08 ` [PATCH] tracing/stack-tracer: avoid races accessing file Török Edwin
2008-11-23 11:20 ` Ingo Molnar
2008-11-25 14:40 ` [PATCH 2/2] tracing: identify which executable object the userspace address belongs to Frank Ch. Eigler
2008-11-26 9:59 ` Török Edwin
2008-11-27 10:41 ` Peter Zijlstra
2008-11-27 12:48 ` Frank Ch. Eigler
2008-11-27 13:02 ` Peter Zijlstra
2008-11-27 13:03 ` Török Edwin
2008-11-27 14:10 ` Ingo Molnar
2008-11-27 14:27 ` Török Edwin [this message]
2008-11-27 14:51 ` Ingo Molnar
2008-12-09 19:49 ` Török Edwin
2008-11-23 8:26 ` [PATCH 0/2] tracing: userspace stacktraces Ingo Molnar
2008-11-23 9:24 ` Török Edwin
2008-11-23 9:30 ` Ingo Molnar
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=492EAE65.1040903@gmail.com \
--to=edwintorok@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=fche@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sandmann@daimi.au.dk \
--cc=srostedt@redhat.com \
--cc=viro@ZenIV.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox