Messages in this thread | | | Date | Tue, 11 Nov 2008 10:43:12 +0100 | From | Ingo Molnar <> | Subject | Re: [RFC v3][PATCH 0/2] Make ftrace able to trace function return |
| |
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> This patchset adds the ability for ftrace to trace the function even > on call time and on return time. So we can now measure the time of > execution of the most part of the functions inside the kernel with > ftrace. > > The first patch bring the low level tools to add the support of > return tracing on X86-32. It is totally separated from the > traditional implementation of ftrace and doesn't support dynamic > ftrace at this time. > > The second patch adds a tracer based on the ring-buffer which > measure the time of execution of the functions inside the kernel.
okay, i've created tip/tracing/function-return-tracer topic so that we can start testing this for real and do can start iterating it via smaller changes. I've also integrated it into tip/master, it's looking good so far.
i did a couple of cleanups straight away:
1) i did a FTRACE_RETURN => FUNCTION_RET_TRACER rename, to move it in line with the function tracer
2) i cleaned up the arch/x86/Kconfig impact:
f1c4be5: tracing, x86: clean up FUNCTION_RET_TRACER Kconfig
the return-tracer builds and boots, and works fabulously:
# cd /sys/debug/tracing/
# cat available_tracers return function sched_switch nop
# echo return > current_tracer clocksource_read+0xd/0xf -> acpi_pm_read (1547 ns) getnstimeofday+0x3e/0xc8 -> clocksource_read (1951 ns) ktime_get_ts+0x25/0x49 -> getnstimeofday (2354 ns) ktime_get_ts+0x45/0x49 -> set_normalized_timespec (120 ns)
Small quirk, it does not seem possible to switch from ftrace to ftrace-ret:
# echo ftrace > current_tracer # echo return > current_tracer bash: echo: write error: Invalid argument
i have to go via the "nop" tracer for this to work. Steve: switching between tracer plugins should be seemless.
Question: have you thought about extending the return-tracer to dyn-function-tracer?
That's where it will really shine: the dftrace workflow is to typically enable a low number of functions - and there the return-tracing overhead does not show up nearly as much as in the static-function-tracing workflow.
Another suggestion: i think the "return" plugin name is confusing to users (it confused me when i first saw it listed in available_tracers).
So lets use "function_full" and "function" tracing perhaps? The "full" tracer is what traces both entry and exit points, and establishes full function-call timings/costs. The "function" tracer is more lightweight and traces function entry events.
Ingo
| |