lkml.org 
[lkml]   [2010]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCH 5/5] perf: Implement perf_output_addr()
    From
    Date
    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





    \
     
     \ /
      Last update: 2010-05-19 17:41    [W:3.294 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site