1. 05 Dec, 2011 5 commits
    • Ingo Molnar's avatar
      Merge branch 'tip/perf/urgent' of... · dc440d10
      Ingo Molnar authored
      Merge branch 'tip/perf/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace into perf/urgent
      dc440d10
    • Ingo Molnar's avatar
    • 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
    • Robert Richter's avatar
      perf, x86: Force IBS LVT offset assignment for family 10h · 16e5294e
      Robert Richter authored
      On AMD family 10h we see firmware bug messages like the following:
      
       [Firmware Bug]: cpu 6, try to use APIC500 (LVT offset 0) for vector 0x10400, but the register is already in use for vector 0xf9 on another cpu
       [Firmware Bug]: cpu 6, IBS interrupt offset 0 not available (MSRC001103A=0x0000000000000100)
       [Firmware Bug]: using offset 1 for IBS interrupts
       [Firmware Bug]: workaround enabled for IBS LVT offset
       perf: AMD IBS detected (0x00000007)
      
      We always see this, since the offsets are not assigned by the BIOS for
      this family. Force LVT offset assignment in this case. If the OS
      assignment fails, fallback to BIOS settings and try to setup this.
      
      The fallback to BIOS settings weakens the family check since
      force_ibs_eilvt_setup() may fail e.g. in case of virtual machines.
      But setup may still succeed if BIOS offsets are correct.
      
      Other families don't have a workaround implemented that assigns LVT
      offsets. It's ok, to drop calling force_ibs_eilvt_setup() for that
      families.
      
      With the patch the [Firmware Bug] messages vanish. We see now:
      
       IBS: LVT offset 1 assigned
       perf: AMD IBS detected (0x00000007)
      Signed-off-by: default avatarRobert Richter <robert.richter@amd.com>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20111109162225.GO12451@erda.amd.comSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      16e5294e
    • Peter Zijlstra's avatar
      perf, x86: Disable PEBS on SandyBridge chips · 6a600a8b
      Peter Zijlstra authored
      Cc: Stephane Eranian <eranian@google.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      6a600a8b
  2. 02 Dec, 2011 1 commit
  3. 16 Nov, 2011 2 commits
  4. 15 Nov, 2011 1 commit
  5. 14 Nov, 2011 8 commits
  6. 13 Nov, 2011 1 commit
  7. 12 Nov, 2011 17 commits
  8. 11 Nov, 2011 5 commits