Skip to content
  1. Dec 06, 2011
  3. Dec 05, 2011
    • 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
      Merge branch 'perf/urgent' of git://github.com/acmel/linux into perf/urgent · 2c3757e5
      Ingo Molnar authored
      2c3757e5
    • 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@quad


Signed-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.com


Signed-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
  5. Dec 02, 2011
  7. Nov 16, 2011
  9. Nov 15, 2011
  11. Nov 14, 2011
  13. Nov 13, 2011
  15. Nov 12, 2011
  17. Nov 11, 2011
    • Shawn Guo's avatar
      arm/imx: fix imx6q mmc error when mounting rootfs · f750ba9b
      Shawn Guo authored 
      

The following error is seen in some case when mounting rootfs from
SD/MMC cards.

  Waiting for root device /dev/mmcblk0p1...
  mmc1: host does not support reading read-only switch. assuming write-enable.
  mmc1: new high speed SDHC card at address b368
  mmcblk0: mmc1:b368 SDC   3.74 GiB
   mmcblk0: p1
  mmc1: Timeout waiting for hardware interrupt.
  mmcblk0: error -110 transferring data, sector 3678224, nr 40, cmd response 0x900, card status 0xc00
  end_request: I/O error, dev mmcblk0, sector 3678225
  Buffer I/O error on device mmcblk0p1, logical block 458754
  lost page write due to I/O error on mmcblk0p1

This patch fixes the problem by lowering the usdhc clock and correcting
watermark configuration.

Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
Cc: Chris Ball <cjb@laptop.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      f750ba9b