lkml.org 
[lkml]   [2008]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] tracing/function-return-tracer: Call prepare_ftrace_return by registers

* Ingo Molnar <mingo@elte.hu> wrote:

> 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.
>
> It definitely must convey the idea that this is a more capable (and
> also more expensive) form of function tracing.

on a related note.

Frederic, it would be nice to fine-tune the tracer output to convey
the callgraph information more clearly. Here's a mockup of a good
default output:

getnstimeofday() {
set_normalized_timespec() {
clocksource_read() {
acpi_pm_read() ( 1547 ns)
} clocksource_read() ( 1951 ns)
} set_normalized_timespec() ( 2200 ns)
} getnstimeofday() ( 2354 ns)

[...]

Such output would be _very_ nice and intuitive to have. Developers
would love it instantly. Note its C-ish syntax - that is obviously the
easiest to parse for kernel developers.

and note how natural it will be in the future to embellish certain
function calls in the above trace, for example with function
arguments:

clocksource_read("acpi_pm") {

i'd suggest to hide the offset bit of the ksym (like the mockup does
it - unless a tracing_option is set for more verbose symbol output).
For these traces it's almost always useless and the context tells us
in 99% of the cases where a function got called.

Easiest would be to add a depth field to the trace entry as well, to
make sure we get the right depth in the end, even if we somehow mix up
the trace entries.

We could also trace function entry and exit separately, and
post-process the call stack (and the cost) during trace output
formatting - not during tracing.

Hm?

Ingo


\
 
 \ /
  Last update: 2008-11-13 10:17    [W:0.094 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site