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, Peter Zijlstra wrote:

> On Sat, 2009-03-21 at 04:26 -0700, 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.
>
> I have to agree with Andrew here, my plan is to remove all the
> profiling stuff from kernel/trace in favour of perf counters.

Well, the branch profilers, I would think, are too heavy for perf
counters.

>
> If you want exact function count profiling we could try to do something
> perf counter based, eg. stick a software counter in the mcount thingy.

I'd like to get the function graph version working, in order to calculate
the times spent in each funtion, then I can see how we can (if possible)
convert it over to perf counters. :-/


>
> After that you'd need to get something like
> this_pt_regs()/caller_pt_regs() which would provide the current kernel
> stack information to generate profile information from.
>
> Current software events use get_irq_regs() ?: task_pt_regs() for lack of
> anything better.

I need to take a deeper look at perf counters. Not sure why pt_regs would
be needed for the function counting. All the information needed is passed
via the mcount call.

-- Steve



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