From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: "Pekka Enberg" <penberg@cs.helsinki.fi>,
"Ingo Molnar" <mingo@elte.hu>, acme <acme@redhat.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
"Eduard-Gabriel Munteanu" <eduard.munteanu@linux360.ro>,
roland <roland@redhat.com>,
"Christoph Hellwig" <hch@infradead.org>,
"Masami Hiramatsu" <mhiramat@redhat.com>,
"Mathieu Desnoyers" <mathieu.desnoyers@polymtl.ca>,
linux-kernel@vger.kernel.org
Subject: Re: malloc() tracing in perf?
Date: Thu, 06 Aug 2009 14:59:34 +0200 [thread overview]
Message-ID: <1249563574.32113.358.camel@twins> (raw)
In-Reply-To: <20090806115527.GE18768@redhat.com>
On Thu, 2009-08-06 at 07:55 -0400, Frank Ch. Eigler wrote:
> Hi -
>
> On Thu, Aug 06, 2009 at 01:28:14PM +0200, Peter Zijlstra wrote:
> > [...]
> > > That work is ongoing, and being discussed on utrace-devel@redhat.com,
> > > since it is a prerequisite.
> >
> > Still hiding the discussion and the design never helped anybody.
>
> I guess "hiding" is a matter of opinion.
Yeah in plain sight where nobody looks, really I thought the idea was to
get utrace upstream, this means posting to linux-kernel. Going on LKML
posts I'd say the utrace project was dead. Same goes for uprobe.
I've told this before and I'll say it again, post to LKML.
> > > While these deliberations are ongoing, you can use systemtap. Probing
> > > random places in userspace is about as casual as probing the kernel:
> >
> > Right, but that still doesn't tell us anything on how you're doing that,
> > does it?
>
> Since you asked... the probe process("/lib64/libc.so.6") points
> systemtap to a shared library file, whose symbol table & debug data
> gives us information about what functions & parameters are available.
> Among other things, we record a shared-library base-relative address
> for the function.
>
> At run time, we monitor the entire system (or just a given process if
> -x PID/-c CMD was specified) to see when that shared library gets
> loaded. (This in turn is done with a utrace-based hook of the mmap
> syscall - see "task_finder" in our sources).
Does this also iterate the already existing tasks to find if it was
already mmap()ed?
> This overview skims over issues related to return probes, tracing
> buffer manipulations, and much other stuff.
Right, so you basically read the (dwarf2) debug info for a particular
lib/symbol and generate a kernel module that knows about that and then
insert that into the kernel to act as a uprobe handler?
Uprobe will then do the code rewrite on mmap() time to insert a trap
much like kprobe does? What if its a JITed code section and the JIT
rewrites it? Will uprobes detect that?
> All the code for this is hidden in plain sight in every systemtap
> release, so please feel free to refer to that and/or ask more detailed
> questions.
I thought the goal was to get stuff upstream, but if you want to
continue living in la-la land and not bother with upstream Linux then so
be it I guess :-(
next prev parent reply other threads:[~2009-08-06 12:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4A7A8ADD.4080208@cs.helsinki.fi>
[not found] ` <1249546610.32113.35.camel@twins>
2009-08-06 8:20 ` malloc() tracing in perf? Pekka Enberg
[not found] ` <4A7A9F7F.7080405@cs.helsinki.fi>
2009-08-06 9:19 ` Pekka Enberg
2009-08-06 9:42 ` Peter Zijlstra
2009-08-06 11:20 ` Frank Ch. Eigler
2009-08-06 11:28 ` Peter Zijlstra
2009-08-06 11:55 ` Frank Ch. Eigler
2009-08-06 12:59 ` Peter Zijlstra [this message]
2009-08-06 13:47 ` Steven Rostedt
2009-08-06 14:17 ` Frank Ch. Eigler
2009-08-06 13:35 ` Mathieu Desnoyers
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=1249563574.32113.358.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=eduard.munteanu@linux360.ro \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
--cc=roland@redhat.com \
--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.