Re: [PATCH 2/2] tracing/function-return-tracer: Call prepare_ftrace_return by registers

[Ingo Molnar <mingo@elte.hu>]

* 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