lkml.org 
[lkml]   [2009]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFD] Kprobes/Kretprobes perf support

* Masami Hiramatsu <mhiramat@redhat.com> wrote:

>> Speaking about your patches. You told recently you would be
>> willing to implement a perf support for kprobes, right? :-)
>
> Hmm, perhaps, I meant a profiling
> interface(http://lkml.org/lkml/2009/7/24/240). However, that is
> interesting idea too.

Note that profiling via perf and perfcounters is a very young
project, but already far more capable:

- It is a generic framework. If you provide an event source, the
full framework will understand and support your events and will
expose it to users: 'perf stat' works, 'perf record',
'perf report', 'perf top' all works the upcoming 'perf trace'
and the upcoming 'perf view' GUI will all understand it. These
are all different modes of analysis, from the high-level
statistics bits, through profiling, down to lowlevel tracing -
based on the same stream of data.

- It's very flexible: there's per cpu, per task or per workload
hierarchy stats/profiling/tracing.

- It can do call-chain graph recording/reporting
(try "perf record -g -f -a sleep 1" + "perf report")

- There's a standard syscall interface to all this, making it
readily accessible and pushing it into apps and tools.

- Your events can and will mix with all the other events. So there
can be hardware PMU events, software counters, tracepoints, etc.
- all in the same data file.

So while there's still a lot of work to do all across the
perfcounters spectrum, it generally would be nice to expose kprobes
events via perfcounters.

Ingo


\
 
 \ /
  Last update: 2009-08-13 10:05    [W:0.143 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site