From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: "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>,
fche <fche@redhat.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: malloc() tracing in perf?
Date: Thu, 06 Aug 2009 11:42:40 +0200 [thread overview]
Message-ID: <1249551760.32113.83.camel@twins> (raw)
In-Reply-To: <4A7AA008.80309@cs.helsinki.fi>
On Thu, 2009-08-06 at 12:19 +0300, Pekka Enberg wrote:
> Pekka Enberg wrote:
> > Hi Peter,
> >
> > On Thu, 2009-08-06 at 10:48 +0300, Pekka Enberg wrote:
> >>> Hi,
> >>>
> >>> It's me again :-).
> >>>
> >>> I have a little user-space application that is pretty memory hungry
> >>> and I want to understand why. I started to google around for a memory
> >>> profiler or a malloc() tracer but didn't seem to find anything really
> >>> useful.
> >>>
> >>> But then it hit me, why can't I have kmemtrace + perf but for
> >>> user-space? Something like the "Malloc Trace" shown here:
> >>>
> >>> http://developer.apple.com/documentation/developertools/conceptual/SharkUserGuide/OtherProfilingandTracingTechniques/OtherProfilingandTracingTechniques.html#//apple_ref/doc/uid/TP40005233-CH6-SW17
> >>>
> >>>
> >>> Does this sound like something that could/should be part of "perf"?
> >>> How would all this work anyway? Can we intercept malloc() and free()
> >>> somehow? Where would the data be pushed? Am I just going perf-crazy
> >>> and trying to turn it into a swiss army knife because it's so easy to
> >>> use?-)
> >
> > Peter Zijlstra wrote:
> >> OK, you just trod into a wasp's nest :-)
> >>
> >> That sounds like uprobes, the equivalent of kprobes but for userspace.
> >>
> >> I seem to have heard people are working on such a thing, but I can't
> >> seem to find a single LKML post with 'uprobe' in the subject in the past
> >> two years or something (except for MTUprobe) -- so I guess its not
> >> really going anywhere any fast.
> >
> > [snip]
> >
> > Right. Are dynamic tracepoints what we want for malloc() and free()
> > interception, though? I guess we can just do generic "userspace function
> > called" events and record the passed parameters. Then "perf memreport"
> > can just go find all the malloc() and free() calls and construct a
> > memory profile out of it?
> >
> > That said, I'd also be interested in wiring my userspace VM garbage
> > collector to emit similar alloc and free events as well (because perf
> > already has a JIT symbol map) which makes me think we want generic
> > "userspace allocated memory" events.
Right, there is the distinction between static and dynamic tracepoints,
and I'm not sure how that'll work out. Most people who've looked at the
subject matter are on CC, so I'm hoping someone will expand.
That said, we could simply LD_PRELOAD malloc and free (new and delete)
like any other memory debugger out there already does, that's not rocket
science (in fact, I've done so on many an occasion).
I remember mpatrol being a hackable code base, but I just looked it up
and its LGPL-v3 so I'm not sure we should be borrowing code from there.
Maybe there is another such creature out there we can borrow code from.
I've got similar ideas for your JIT stuff, you now open-code the tmp
file writing, ideally I'd like to push that into a library and have you
link against something with weak stubs and let perf LD_PRELOAD real code
which will do whatever is needed. That'd rid you of having to know about
where and what to write.
Anyway, malloc/free are easy, but like you say, you might be interested
in other functions which aren't as easy.
next prev parent reply other threads:[~2009-08-06 9:42 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 [this message]
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
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=1249551760.32113.83.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox