Messages in this thread | | | Date | Thu, 26 Mar 2009 09:07:57 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH 0/2] [GIT PULL] function profiler updates |
| |
* Steven Rostedt <rostedt@goodmis.org> wrote:
> > Ingo, > > Please pull the latest rfc/tip/tracing/function-profiler tree, which can be found at: > > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git > rfc/tip/tracing/function-profiler > > > Steven Rostedt (2): > tracing: remove on the fly allocator from function profiler > tracing: add average time in function to function profiler > > ---- > kernel/trace/ftrace.c | 97 +++++++++++++++++++++++++++++-------------------- > 1 files changed, 57 insertions(+), 40 deletions(-) > --
Pulled, thanks Steve. The on-the-fly allocator was my main conceptual worry about this.
How useful this kind of profiling will end up being in practice remains to be seen - but it does have a handful of unique properties that cannot be dismissed.
It's main downside is its overhead - sampling based profilers are a lot more lightweight and allow unintrusive inspection of workloads.
The upside of it are all the things that this profiling overhead allows us to do:
- 100% precise, non-sampling profiling
- accurate profiles possible with very short, bursty workloads too
- filtering capabilities of the tracing subsystem allow the flexible shaping of the set of functions and the set of conditions that are profiled: there's the regex filter and there's also the tracepoint based filter expressions.
- it also allowsuser-space driven filtering: if user-space wants to profile just one specific functionality (say the function calls of one specific library), they can use /debug/tracing/enabled fast toggle to turn profiling on/off runtime. This can be done at a very high frequency as well.
- developers can switch between profiling and tracing mode seemlessly. This allows multiple 'dimensions' of the same workload to be observed, via the same set of facilities.
Ingo
| |