1. 07 12月, 2010 2 次提交
    • M
      kprobes: Cleanup disabling and unregistering path · 6f0f1dd7
      Masami Hiramatsu 提交于
      Merge disabling kprobe to unregistering kprobe function
      and add comments for disabing/unregistring process.
      
      Current unregistering code disables(disarms) kprobes after
      checking target kprobe status. This patch changes it to
      disabling kprobe first after that it changing the kprobe's
      state. This allows to share probe disabling code between
      disable_kprobe() and unregister_kprobe().
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: 2nddept-manager@sdl.hitachi.co.jp
      LKML-Reference: <20101203095356.2961.30152.stgit@ltc236.sdl.hitachi.co.jp>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6f0f1dd7
    • M
      kprobes: Rename old_p to more appropriate name · 6d8e40a8
      Masami Hiramatsu 提交于
      Rename irrelevant uses of "old_p" to more appropriate names.
      Originally, "old_p" just meant "the old kprobe on given address"
      but current code uses that name as "just another kprobe" or
      something like that. This patch renames those pointer names
      to more appropriate one for maintainability.
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: 2nddept-manager@sdl.hitachi.co.jp
      LKML-Reference: <20101203095350.2961.48110.stgit@ltc236.sdl.hitachi.co.jp>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6d8e40a8
  2. 02 12月, 2010 17 次提交
  3. 01 12月, 2010 14 次提交
  4. 27 11月, 2010 5 次提交
    • A
      perf tools: Fix lost and unknown events handling · 068ffaa8
      Arnaldo Carvalho de Melo 提交于
      Fix it by explaining what can be happening and giving the number of processed
      and lost events.
      
      Also holler if unknown events were found, that can be due to processing a
      perf.data file collected using a newer tool where newer events got added on
      reporting using an older perf tool, that or a bug, so ask for a report to be
      made.
      
      Works on both --tui and --stdio.
      Suggested-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      068ffaa8
    • S
      perf trace: Handle DT_UNKNOWN on filesystems that don't support d_type · 008f29d3
      Shawn Bohrer 提交于
      Some filesystems like xfs and reiserfs will return DT_UNKNOWN for the
      d_type.  Handle this case by calling stat() to determine the type.
      
      Cc: Andreas Schwab <schwab@linux-m68k.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1290355779-3276-1-git-send-email-sbohrer@rgmadvisors.com>
      Signed-off-by: NShawn Bohrer <sbohrer@rgmadvisors.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      008f29d3
    • I
      perf symbols: Correct final kernel map guesses · 9d1faba5
      Ian Munsie 提交于
      If a 32bit userspace perf is running on a 64bit kernel, the end of the final
      map in the kernel would incorrectly be set to 2^32-1 rather than 2^64-1.
      
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1290658375-10342-1-git-send-email-imunsie@au1.ibm.com>
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9d1faba5
    • A
      perf events: Default to using event__process_lost · 37982ba0
      Arnaldo Carvalho de Melo 提交于
      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: NThomas 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: NArnaldo Carvalho de Melo <acme@redhat.com>
      37982ba0
    • A
      perf record: Add option to disable collecting build-ids · baa2f6ce
      Arnaldo Carvalho de Melo 提交于
      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: NThomas 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: NArnaldo Carvalho de Melo <acme@redhat.com>
      baa2f6ce
  5. 26 11月, 2010 2 次提交