Messages in this thread | | | Date | Thu, 4 Mar 2010 12:25:31 +0100 | From | Ingo Molnar <> | Subject | Re: [RFC][PATCH 2/3] perf: Take a hot regs snapshot for trace events |
| |
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2010-03-03 at 12:07 -0500, Steven Rostedt wrote: > > oops, my bad :-), I thought this was in the x86 arch directory. For the > > University, I was helping them with adding trace points for page faults > > when I came across this in arch/x86/mm/fault.c: > > > > perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, 0, regs, address); > > > > > > This is what I actually was wondering about. Why is it a "perf only" trace > > point instead of a TRACE_EVENT()? > > Because I wanted to make perf usable without having to rely on funny > tracepoints. That is, I am less worried about committing software counters > to ABI than I am about TRACE_EVENT(), which still gives me a terribly > uncomfortable feeling.
I'd still like a much less error-prone and work-intense way of doing it.
I'd suggest we simply add a TRACE_EVENT_ABI() for such cases, where we really want to expose a tracepoint to tooling, programmatically. Maybe even change the usage sites to trace_foo_ABI(), to make it really clear and to make people aware of the consequences.
> Also, building with all CONFIG_TRACE_*=n will still yield a usable perf, > which is something the embedded people might fancy, all that TRACE stuff > adds lots of code.
Not a real issue i suspect when you do lock profiling ...
Or if it is, some debloating might be in order - and the detaching of event enumeration and ftrace TRACE_EVENT infrastructure from other ftrace bits. (i suggested an '/eventfs' special filesystem before, for nicely layed out hierarchy of ftrace/perf events.)
Thanks,
Ingo
| |