• Peter Zijlstra's avatar
    perf: Fix loss of notification with multi-event · 10c6db11
    Peter Zijlstra authored
    When you do:
            $ perf record -e cycles,cycles,cycles noploop 10
    
    You expect about 10,000 samples for each event, i.e., 10s at
    1000samples/sec. However, this is not what's happening. You
    get much fewer samples, maybe 3700 samples/event:
    
    $ perf report -D | tail -15
    Aggregated stats:
               TOTAL events:      10998
                MMAP events:         66
                COMM events:          2
              SAMPLE events:      10930
    cycles stats:
               TOTAL events:       3644
              SAMPLE events:       3644
    cycles stats:
               TOTAL events:       3642
              SAMPLE events:       3642
    cycles stats:
               TOTAL events:       3644
              SAMPLE events:       3644
    
    On a Intel Nehalem or even AMD64, there are 4 counters capable
    of measuring cycles, so there is plenty of space to measure those
    events without multiplexing (even with the NMI watchdog active).
    And even with multiplexing, we'd expect roughly the same number
    of samples per event.
    
    The root of the problem was that when the event that caused the buffer
    to become full was not the first event passed on the cmdline, the user
    notification would get lost. The notification was sent to the file
    descriptor of the overflowed event but the perf tool was not polling
    on it.  The perf tool aggregates all samples into a single buffer,
    i.e., the buffer of the first event. Consequently, it assumes
    notifications for any event will come via that descriptor.
    
    The seemingly straight forward solution of moving the waitq into the
    ringbuffer object doesn't work because of life-time issues. One could
    perf_event_set_output() on a fd that you're also blocking on and cause
    the old rb object to be freed while its waitq would still be
    referenced by the blocked thread -> FAIL.
    
    Therefore link all events to the ringbuffer and broadcast the wakeup
    from the ringbuffer object to all possible events that could be waited
    upon. This is rather ugly, and we're open to better solutions but it
    works for now.
    Reported-by: default avatarStephane Eranian <eranian@google.com>
    Finished-by: default avatarStephane Eranian <eranian@google.com>
    Reviewed-by: default avatarStephane Eranian <eranian@google.com>
    Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20111126014731.GA7030@quadSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
    10c6db11
core.c 164 KB