From: Ingo Molnar <mingo@elte.hu>
To: "Frédéric Weisbecker" <fweisbec@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] tracing/function-return-tracer: Call prepare_ftrace_return by registers
Date: Thu, 13 Nov 2008 10:44:12 +0100 [thread overview]
Message-ID: <20081113094412.GL25479@elte.hu> (raw)
In-Reply-To: <c62985530811130138v69b260dcy59adfba24afee0ca@mail.gmail.com>
* Frédéric Weisbecker <fweisbec@gmail.com> wrote:
> 2008/11/13 Ingo Molnar <mingo@elte.hu>:
> > hm, function-exit is a quite bad name i think that tells nothing to
> > the user. I like "function-cost tracer" because that tells the user
> > what it's all about in the end.
> >
> > Or perhaps we could name it the "callgraph" tracer? (as opposed to the
> > simpler function tracer which traces function entries) Note that we
> > could use the output to build function call coverage graphs.
>
> But you can build a call graph with the function tracer, that what
> does the script draw_trace.py in a bit loosely way for example.
yes, but not reliably so - there's no guaranteed callgraph structure.
With entry tracing we have entry+parent events, but especially across
longer callchains there's no truly guaranteed way to preserve the full
graph.
> IMHO, function cost measurement or call graphs are particular uses
> that can be made of this engine. You can also use it to trace
> function return values for example.
yes. The mockup output has place for that.
> So perhaps naming it by thinking on the purpose it could be use at
> most would be better that its "general" or "potential" purpose. I
> don't know...
i suggested "full-function" tracer name before, but that sounds a bit
quirky too.
Perhaps this should be the function-tracer, and the entry tracer would
be the function-entry tracer?
Ingo
next prev parent reply other threads:[~2008-11-13 9:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-12 21:49 [PATCH 2/2] tracing/function-return-tracer: Call prepare_ftrace_return by registers Frederic Weisbecker
2008-11-12 22:16 ` Ingo Molnar
2008-11-12 22:22 ` Frédéric Weisbecker
2008-11-12 23:25 ` Steven Rostedt
2008-11-12 23:35 ` Frédéric Weisbecker
2008-11-13 0:11 ` Steven Rostedt
2008-11-13 8:59 ` Ingo Molnar
2008-11-13 9:14 ` Ingo Molnar
2008-11-13 10:02 ` Frédéric Weisbecker
2008-11-13 10:09 ` Ingo Molnar
2008-11-13 23:48 ` Frédéric Weisbecker
2008-11-13 9:38 ` Frédéric Weisbecker
2008-11-13 9:40 ` Frédéric Weisbecker
2008-11-13 9:44 ` Ingo Molnar [this message]
2008-11-17 18:58 ` Frederic 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:
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=20081113094412.GL25479@elte.hu \
--to=mingo@elte.hu \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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.