LKML Archive on
help / color / mirror / Atom feed
From: Ananth N Mavinakayanahalli <>
To: Ingo Molnar <>
Cc: "Steven Rostedt" <>,
	"Jim Keniston" <>
Subject: Re: [RFC][PATCH] Make ftrace able to trace function return
Date: Mon, 3 Nov 2008 16:46:02 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Oct 30, 2008 at 08:26:21PM +0100, Ingo Molnar wrote:
> * Steven Rostedt <> wrote:
> > gcc -c -finstrument-functions traceme.c
> > This is not 5 extra bytes but 27 extra bytes for a total of 32 bytes 
> > at every function. Also note that this also adds these calls to 
> > inline functions as well. We could easly stop that by adding 
> > "notrace" to the inline define (which I've done).
> > 
> > But this would make the patching a bit more difficult (not 
> > impossible). But it will bloat the image quite a bit.
> yeah, i too knew it was expensive, but didnt realize it's this bloaty. 
> It's a non-starter really.
> How reliable can we make Frederic's trampoline approach? Especially 
> with the opt-in function filters of dyn-ftrace, there's real value in 
> the trampoline approach IMO (we could display real function cost, 
> etc.), and the runtime cost should be OK as long we dont probe a ton 
> of functions all the time. (and it's optional anyway)

Something similar to Frederic's trampoline approach is what we use for
kretprobes. Recently, it's also acquired the capability to run handlers
at function entry. See samples/kprobes/kretprobe_example.c -- it
currently can print the time spent in any user-specified kernel routine.

Of course, this approach is not cheap... since it's kprobe based, we
have two exceptions -- but it is reliable. You are limited by the number
of slots available to record return addresses for each invocation,
especially if functions are reentrant, in the hotpath and can sleep.

There were other issues encountered during its implementation (some
of them 'cos we hash instances on the task) were with routines that are
entered/exited in different task contexts, noret type functions, etc.


  reply	other threads:[~2008-11-03 11:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-30 19:20 Frederic Weisbecker
2008-10-30 18:20 ` Ingo Molnar
2008-10-30 18:30   ` Frédéric Weisbecker
2008-10-30 18:37     ` Ingo Molnar
2008-10-30 19:17       ` Steven Rostedt
2008-10-30 19:26         ` Ingo Molnar
2008-11-03 11:16           ` Ananth N Mavinakayanahalli [this message]
2008-11-03 13:32             ` Frédéric Weisbecker
2008-10-31  1:35       ` Frédéric Weisbecker
2008-10-30 20:30 ` Steven Rostedt
2008-10-31  0:05   ` Frédéric Weisbecker
2008-10-31  2:43     ` Steven Rostedt
2008-10-31 20:18       ` Frederic Weisbecker
2008-11-03 10:06         ` Ingo Molnar
2008-11-03 13:11           ` Frédéric Weisbecker

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \
    --cc==?iso-8859-1?Q?Fr=E9d=E9ric_Weisbecker_=3Cfweisbec=40gmail=2Ecom=3E? \ \ \ \ \
    --subject='Re: [RFC][PATCH] Make ftrace able to trace function return' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).