All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Enberg <penberg@cs.helsinki.fi>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
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:20:42 +0300	[thread overview]
Message-ID: <4A7A925A.90606@cs.helsinki.fi> (raw)
In-Reply-To: <1249546610.32113.35.camel@twins>

Peter Zijlstra wrote:
> 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?-)
> 
> 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.
> 
> Now doing probes on userspace is hard because you need to know more
> about the userspace bits than a kernel really ought to be interested in.
> 
> Then again, the only way to extract bits from userspace is to stop it --
> now one could do that using [pu]trace and have some monitoring app prod
> at it like any other debugger would, and I think this is the approach
> suggested by some (hch iirc).
> 
> Others seem to think we ought to stuff all this into the kernel, I can
> only imagine the pain that will cause, since you need to teach the
> kernel about these instrumentation sites' context, so I can only imagine
> it'd be through a kernel module interface much like system-tap does
> (they would be doing the in-kernel bit).
> 
> Then there are the tracer folks who also want to collect userspace
> traces. Some have proposed a sys_trace() call, others want to play silly
> games with mmap() and then there is the uprobe idea. Others (tglx and
> me) proposed letting userspace log itself and post-merge all the various
> trace buffers to get a complete picture.
> 
> 
> Anyway, like you say, it has uses (potentially very powerful ones),
> Sun/Apple do it with Dtrace, Linux wants it but I don't think we quite
> agreed on how to do it :-)
> 
> 
> And here I see LKML isn't on the CC list, perhaps we should?

Oh sure, lets do that, half of the people seem to be on the CC anyway 
now :-).

			Pekka

       reply	other threads:[~2009-08-06  8:20 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   ` Pekka Enberg [this message]
     [not found]   ` <4A7A9F7F.7080405@cs.helsinki.fi>
2009-08-06  9:19     ` malloc() tracing in perf? 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
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=4A7A925A.90606@cs.helsinki.fi \
    --to=penberg@cs.helsinki.fi \
    --cc=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=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.