1. 06 12月, 2010 2 次提交
    • C
      perf tools: Catch a few uncheck calloc/malloc's · ce47dc56
      Chris Samuel 提交于
      There were a few stray calloc()'s and malloc()'s which were not having
      their return values checked for success.
      
      As the calling code either already coped with failure or didn't actually
      care we just return -ENOMEM at that point.
      
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NChris Samuel <chris@csamuel.org>
      LKML-Reference: <4CDDF95A.1050400@csamuel.org>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ce47dc56
    • S
      perf script: Fix compiler warning in builtin_script.c:is_top_script() · 965bb6be
      Stephane Eranian 提交于
      Fix annoying compiler warning in the is_top_script() function.
      
      The issue was that a const char * was cast into a char * to call
      ends_with(). We fix the users of ends_with() instead. Some are passing a
      char *, but it is okay to cast the return value of ends_with() to char *
      (because we understand what ends_with() does).
      
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Stephane Eranian <eranian@gmail.com>
      LKML-Reference: <4cf92096.17edd80a.1540.5d60@mx.google.com>
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      965bb6be
  2. 07 12月, 2010 3 次提交
    • T
      perf session: Sort all events if ordered_samples=true · cbf41645
      Thomas Gleixner 提交于
      Now that we have timestamps on FORK, EXIT, COMM, MMAP events we can
      sort everything in time order. This fixes the following observed
      problem:
      
      mmap(file1) -> pagefault() -> munmap(file1)
      mmap(file2) -> pagefault() -> munmap(file2)
      
      Resulted in decoding both pagefaults in file2 because the file1 map
      was already replaced by the file2 map when the map address was
      identical.
      
      With all events sorted we decode both pagefaults correctly.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ian Munsie <imunsie@au1.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      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>
      LKML-Reference: <alpine.LFD.2.00.1012051220450.2653@localhost6.localdomain6>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cbf41645
    • A
      perf options: add OPT_CALLBACK_DEFAULT_NOOPT · e4e18d56
      Akihiro Nagai 提交于
      Add new macro OPT_CALLBACK_DEFAULT_NOOPT for parse_options.
      
      It enables to pass the default value (opt->defval) to the callback function
      processing options require no argument.
      Reviewed-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <20101203035853.7827.17502.stgit@localhost6.localdomain6>
      Signed-off-by: NAkihiro Nagai <akihiro.nagai.hw@hitachi.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e4e18d56
    • I
      perf hist: Better displaying of unresolved DSOs and symbols · 1437a30a
      Ian Munsie 提交于
      In the event that a DSO has not been identified, just print out [unknown]
      instead of the instruction pointer as we previously were doing, which is pretty
      meaningless for a shared object (at least to the users perspective).
      
      The IP we print out is fairly meaningless in general anyway - it's just one
      (the first) of the many addresses that were lumped together as unidentified,
      and could span many shared objects and symbols. In reality if we see this
      [unknown] output then the report -D output is going to be more useful anyway as
      we can see all the different address that it represents.
      
      If we are printing the symbols we are still going to see this IP in that column
      anyway since they shouldn't resolve either.
      
      This patch also changes the symbol address printouts so that they print out 0x
      before the address, are left aligned, and changes the %L format string (which
      relies on a glibc bug) to %ll.
      
      Before:
          74.11%    :3259               4a6c  [k]     4a6c
      After:
          74.11%    :3259  [unknown]          [k] 0x4a6c
      
      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>
      LKML-Reference: <1291603026-11785-2-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>
      1437a30a
  3. 05 12月, 2010 2 次提交
    • A
      perf tools: Ask for ID PERF_SAMPLE_ info on all PERF_RECORD_ events · 9c90a61c
      Arnaldo Carvalho de Melo 提交于
      So that we can use -T == --timestamp, asking for PERF_SAMPLE_TIME:
      
        $ perf record -aT
        $ perf report -D | grep PERF_RECORD_
        <SNIP>
         3   5951915425 0x47530 [0x58]: PERF_RECORD_SAMPLE(IP, 1): 16811/16811: 0xffffffff8138c1a2 period: 215979 cpu:3
         3   5952026879 0x47588 [0x90]: PERF_RECORD_SAMPLE(IP, 1): 16811/16811: 0xffffffff810cb480 period: 215979 cpu:3
         3   5952059959 0x47618 [0x38]: PERF_RECORD_FORK(6853:6853):(16811:16811)
         3   5952138878 0x47650 [0x78]: PERF_RECORD_SAMPLE(IP, 1): 16811/16811: 0xffffffff811bac35 period: 431478 cpu:3
         3   5952375068 0x476c8 [0x30]: PERF_RECORD_COMM: find:6853
         3   5952395923 0x476f8 [0x50]: PERF_RECORD_MMAP 6853/6853: [0x400000(0x25000) @ 0]: /usr/bin/find
         3   5952413756 0x47748 [0xa0]: PERF_RECORD_SAMPLE(IP, 1): 6853/6853: 0xffffffff810d080f period: 859332 cpu:3
         3   5952419837 0x477e8 [0x58]: PERF_RECORD_MMAP 6853/6853: [0x3f44600000(0x21d000) @ 0]: /lib64/ld-2.5.so
         3   5952437929 0x47840 [0x48]: PERF_RECORD_MMAP 6853/6853: [0x7fff7e1c9000(0x1000) @ 0x7fff7e1c9000]: [vdso]
         3   5952570127 0x47888 [0x58]: PERF_RECORD_MMAP 6853/6853: [0x3f46200000(0x218000) @ 0]: /lib64/libselinux.so.1
         3   5952623637 0x478e0 [0x58]: PERF_RECORD_MMAP 6853/6853: [0x3f44a00000(0x356000) @ 0]: /lib64/libc-2.5.so
         3   5952675720 0x47938 [0x58]: PERF_RECORD_MMAP 6853/6853: [0x3f44e00000(0x204000) @ 0]: /lib64/libdl-2.5.so
         3   5952710080 0x47990 [0x58]: PERF_RECORD_MMAP 6853/6853: [0x3f45a00000(0x246000) @ 0]: /lib64/libsepol.so.1
         3   5952847802 0x479e8 [0x58]: PERF_RECORD_SAMPLE(IP, 1): 6853/6853: 0xffffffff813897f0 period: 1142536 cpu:3
        <SNIP>
      
      First column is the cpu and the second the timestamp.
      
      That way we can investigate problems in the event stream.
      
      If the new perf binary is run on an older kernel, it will disable this feature
      automatically.
      Tested-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NIan Munsie <imunsie@au1.ibm.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Ian Munsie <imunsie@au1.ibm.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>
      LKML-Reference: <1291318772-30880-5-git-send-email-acme@infradead.org>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9c90a61c
    • A
      perf session: Parse sample earlier · 640c03ce
      Arnaldo Carvalho de Melo 提交于
      At perf_session__process_event, so that we reduce the number of lines in eache
      tool sample processing routine that now receives a sample_data pointer already
      parsed.
      
      This will also be useful in the next patch, where we'll allow sample the
      identity fields in MMAP, FORK, EXIT, etc, when it will be possible to see (cpu,
      timestamp) just after before every event.
      
      Also validate callchains in perf_session__process_event, i.e. as early as
      possible, and keep a counter of the number of events discarded due to invalid
      callchains, warning the user about it if it happens.
      
      There is an assumption that was kept that all events have the same sample_type,
      that will be dealt with in the future, when this preexisting limitation will be
      removed.
      Tested-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NIan Munsie <imunsie@au1.ibm.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Ian Munsie <imunsie@au1.ibm.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>
      LKML-Reference: <1291318772-30880-4-git-send-email-acme@infradead.org>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      640c03ce
  4. 02 12月, 2010 16 次提交
  5. 01 12月, 2010 12 次提交
  6. 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