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, Andrew Morton wrote:

> 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.

Actually, it would not be too hard to hook this to the function graph
tracer and make the list not only # of hits, but also the time spent in
each function.

-- Steve



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