Re: [RFC][PATCH 2/3] perf: Take a hot regs snapshot for traceevents
From: Steven Rostedt
Date: Thu Mar 04 2010 - 10:16:50 EST
On Thu, 2010-03-04 at 12:25 +0100, Ingo Molnar wrote:
> * Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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.
Would this still be available as a normal trace event?
> > 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.)
Actually, we already have a way to decouple it.
include/trace/define_trace.h is the file that just adds the tracepoint
that is needed.
include/trace/ftrace.h is the file that does the magic and adds the code
for callbacks and tracing.
The perf hooks probably should not have gone in that file and been put
into a include/trace/perf.h file, and then in define_trace.h we would
This should be done anyway. But it would also let you decouple ftrace
trace events from perf trace events but still let the two use the same
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/