All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: "Török Edwin" <edwintorok@gmail.com>,
	"Peter Zijlstra" <a.p.zijlstra@chello.nl>
Cc: "Frank Ch. Eigler" <fche@redhat.com>,
	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 15:51:02 +0100	[thread overview]
Message-ID: <20081127145102.GC4672@elte.hu> (raw)
In-Reply-To: <492EAE65.1040903@gmail.com>


* Török Edwin <edwintorok@gmail.com> wrote:

> Thanks. I can move on to the lock latency tracing ;)

that's a bit more contentious ...

> 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).

> 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).

yes. The less intrusive your patch is, the more you utilize and 
generalize existing facilities, the better. You could split the 
Kconfig of LOCKSTAT into two bits: LOCKSTAT (core) and LOCKSTAT_PROC, 
where the proc bits are enabled separately.

Your tracing approach could then reuse much of core LOCKSTAT (without 
even touching the code) and just plain "select LOCKSTAT" - without 
creating /proc/lockdep_stats.

Peter, what do you think?

	Ingo

  reply	other threads:[~2008-11-27 14:51 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
2008-11-27 14:51               ` Ingo Molnar [this message]
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=20081127145102.GC4672@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=edwintorok@gmail.com \
    --cc=fche@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.