lkml.org 
[lkml]   [2009]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH][GIT PULL] tracing: add function profiler
On Sat, 21 Mar 2009 00:37:59 -0400 (EDT) Steven Rostedt <rostedt@goodmis.org> wrote:

> This patch adds a function profiler. In debugfs/tracing/ two new
> files are created.
>
> function_profile_enabled - to enable or disable profiling
>
> trace_stat/functions - the profiled functions.
>
> For example:
>
> echo 1 > /debugfs/tracing/function_profile_enabled
> ./hackbench 50
> echo 0 > /debugfs/tracing/function_profile_enabled
>
> yields:
>
> cat /debugfs/tracing/trace_stat/functions
>
> Function Hit
> -------- ---
> _spin_lock 10106442
> _spin_unlock 10097492
> kfree 6013704
> _spin_unlock_irqrestore 4423941
> _spin_lock_irqsave 4406825
> __phys_addr 4181686
> __slab_free 4038222
> dput 4030130
> path_put 4023387
> unroll_tree_refs 4019532
> [...]
>
> The most hit functions are listed first. Functions that are not
> hit are not listed.

Why is this useful?

Can we think of any scenarios where kernel developers would get
useful-to-them results from this? Results which couldn't be
obtained by other similarly-accessible means?

<strains a bit>

I guess that one could run workload A, look at
/debugfs/tracing/trace_stat/functions changes, then run worklaod B, then
look at its /debugfs/tracing/trace_stat/functions changes, then somehow
glean some information about the differences between the effects of the two
workloads on the kernel. Or something.

But in this rather fake example and, I suspect, in many others, the result
will be less useful than using oprofile/etc in the same fashion.



\
 
 \ /
  Last update: 2009-03-21 12:39    [W:0.046 / U:3.580 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site