Skip to content

L
linux
Switch branch/tag
  1. 05 Dec, 2010 1 commit
  3. 02 Dec, 2010 1 commit
  5. 01 Dec, 2010 19 commits
  7. 30 Nov, 2010 11 commits
  9. 27 Nov, 2010 3 commits
  11. 26 Nov, 2010 5 commits
    • Arnaldo Carvalho de Melo's avatar
      perf events: Default to using event__process_lost · 37982ba0
      Arnaldo Carvalho de Melo authored 
      Tool developers have to fill in a 'perf_event_ops' method table to
specify how to handle each event, so far the ones that were not
explicitely especified would get a stub that would just discard the
event.

Change that so that tool developers can get the lost event details and
the total number of such events at the end of 'perf report -D' output.
Suggested-by: default avatarThomas Gleixner <tglx@linutronix.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
CC: Thomas Gleixner <tglx@linutronix.de>
Cc: Tom Zanussi <tzanussi@gmail.com>
LKML-Reference: <new-submission>
Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      37982ba0
    • Arnaldo Carvalho de Melo's avatar
      perf record: Add option to disable collecting build-ids · baa2f6ce
      Arnaldo Carvalho de Melo authored 
      Collecting build-ids for long running sessions may take a long time
because it needs to traverse the whole just collected perf.data stream
of events, marking the DSOs that had hits and then looking for the
.note.gnu.build-id ELF section.

For things like the 'trace' tool that records and right away consumes
the data on systems where its unlikely that the DSOs being monitored
will change while 'trace' runs, it is desirable to remove build id
collection, so add a -B/--no-buildid option to perf record to allow such
use case.

Longer term we'll avoid all this if we, at DSO load time, in the kernel,
take advantage of this slow code path to collect the build-id and stash
it somewhere, so that we can insert it in the PERF_RECORD_MMAP event.
Reported-by: default avatarThomas Gleixner <tglx@linutronix.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tom Zanussi <tzanussi@gmail.com>
LKML-Reference: <new-submission>
Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      baa2f6ce
    • Cyrill Gorcunov's avatar
      perf, x86: P4 PMU - describe config format · af86da53
      Cyrill Gorcunov authored 
      Add description of .config in a sake of RAW events.
At least this should bring some light to those who
will be reading this code.
Signed-off-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
Reviewed-by: default avatarStephane Eranian <eranian@google.com>
Cc: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      af86da53
    • Peter Zijlstra's avatar
      perf, arch: Cleanup perf-pmu init vs lockup-detector · 004417a6
      Peter Zijlstra authored 
      The perf hardware pmu got initialized at various points in the boot,
some before early_initcall() some after (notably arch_initcall).

The problem is that the NMI lockup detector is ran from early_initcall()
and expects the hardware pmu to be present.

Sanitize this by moving all architecture hardware pmu implementations to
initialize at early_initcall() and move the lockup detector to an explicit
initcall right after that.

Cc: paulus <paulus@samba.org>
Cc: davem <davem@davemloft.net>
Cc: Michael Cree <mcree@orcon.net.nz>
Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
Acked-by: default avatarWill Deacon <will.deacon@arm.com>
Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1290707759.2145.119.camel@laptop>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      004417a6
    • Andi Kleen's avatar
      x86: Set cpu masks before calling CPU_STARTING notifiers · 5ef428c4
      Andi Kleen authored 
      When booting up a CPU set the various topology masks before
calling the CPU_STARTING notifier. This way the notifier
can actually use the masks.

This is needed for a perf change.
Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1290077254-12165-2-git-send-email-andi@firstfloor.org>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      5ef428c4
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7