Messages in this thread | | | Date | Thu, 13 Aug 2009 10:02:45 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |