Messages in this thread | | | Subject | Re: [RFC PATCH 5/5] perf: Implement perf_output_addr() | From | Steven Rostedt <> | Date | Wed, 19 May 2010 11:38:12 -0400 |
| |
On Wed, 2010-05-19 at 17:05 +0200, Peter Zijlstra wrote: > On Wed, 2010-05-19 at 10:47 -0400, Steven Rostedt wrote: > > On Wed, 2010-05-19 at 09:58 +0200, Peter Zijlstra wrote: > > > On Wed, 2010-05-19 at 09:21 +0200, Frederic Weisbecker wrote: > > > > > > > I'm still not sure what you mean here by this multiplexing. Is > > > > this about per cpu multiplexing? > > > > > > Suppose there's two events attached to the same tracepoint. Will you > > > write the tracepoint twice and risk different data in each, or will you > > > do it once and copy it into each buffer? > > > > Is this because the same function deals with the same tracepoint, and > > has difficulty in knowing which event it is dealing with? > > No, but suppose the tracepoint has a racy expression in it. Having to > evaluate { assign; } multiple times could yield different results, which > in turn means you have to run the filter multiple times too, etc..
I'm still a bit confused by what you mean here. Could you show an example?
> > Although I suppose you could delay the commit of the first even and copy > from there into the next events, but that might give rather messy code. > > > Note, the shrinking of the TRACE_EVENT() code that I pushed (and I'm > > hoping makes it to 35 since it lays the ground work for lots of features > > on top of TRACE_EVENT()), allows you to pass private data to each probe > > registered to the tracepoint. Letting the same function handle two > > different activities, or different tracepoints. > > tracepoint_probe_register() is useless, it requires scheduling. I > currently register a probe on pref_event creation and then maintain a > per-cpu hlist of active events.
When is perf_event creation? When the user runs the code or at boot up?
> > > > > There is another problem. We need something like > > > > perf_output_discard() in case the filter reject the event (which > > > > must be filled for this check to happen). > > > > > > Yeah, I utterly hate that, I opted to let anything with a filter take > > > the slow path. Not only would I have to add a discard, but I'd have to > > > decrement the counter as well, which is a big no-no. > > > > Hmm, this would impact performance on system wide recording of events > > that are filtered. One would think adding a filter would speed things > > up, not slow it down. > > Depends, actually running the filter and backing out might take more > time than simply logging it, esp if you've already done all of the work > and only lack a commit.
Hmm, could be, don't know for sure. I just want to keep the macro magic to a minimum ;-)
-- Steve
| |