1. 21 1月, 2014 1 次提交
  2. 10 12月, 2013 1 次提交
    • A
      perf script: Add an option to print the source line number · cc8fae1d
      Adrian Hunter 提交于
      Add field 'srcline' that displays the source file name and line number
      associated with the sample ip.  The information displayed is the same as
      from addr2line.
      
       $ perf script -f comm,tid,pid,time,ip,sym,dso,symoff,srcline
                  grep 10701/10701 2497321.421013:  ffffffff81043ffa native_write_msr_safe+0xa ([kernel.kallsyms])
        /usr/src/debug/kernel-3.9.fc17/linux-3.9.10-100.fc17.x86_64/arch/x86/include/asm/msr.h:95
                  grep 10701/10701 2497321.421984:  ffffffff8165b6b3 _raw_spin_lock+0x13 ([kernel.kallsyms])
        /usr/src/debug/kernel-3.9.fc17/linux-3.9.10-100.fc17.x86_64/arch/x86/include/asm/spinlock.h:54
                  grep 10701/10701 2497321.421990:  ffffffff810b64b3 tick_sched_timer+0x53 ([kernel.kallsyms])
        /usr/src/debug/kernel-3.9.fc17/linux-3.9.10-100.fc17.x86_64/kernel/time/tick-sched.c:840
                  grep 10701/10701 2497321.421992:  ffffffff8106f63f run_timer_softirq+0x2f ([kernel.kallsyms])
        /usr/src/debug/kernel-3.9.fc17/linux-3.9.10-100.fc17.x86_64/kernel/timer.c:1372
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1386315778-11633-3-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cc8fae1d
  3. 14 10月, 2013 2 次提交
  4. 09 10月, 2013 1 次提交
  5. 11 9月, 2013 1 次提交
    • S
      perf tools: Add attr->mmap2 support · 5c5e854b
      Stephane Eranian 提交于
      This patch adds support for the new PERF_RECORD_MMAP2 record type
      exposed by the kernel. This is an extended PERF_RECORD_MMAP record.
      
      It adds for each file-backed mapping the device major, minor number and
      the inode number and generation.
      
      This triplet uniquely identifies the source of a file-backed mapping. It
      can be used to detect identical virtual mappings between processes, for
      instance.
      
      The patch will prefer MMAP2 over MMAP.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1377079825-19057-3-git-send-email-eranian@google.com
      [ Cope with 314add6b "Change machine__findnew_thread() to set thread pid",
        fix 'perf test' regression test entry affected,
        use perf_missing_features.mmap2 to fallback to not using .mmap2 in older kernels,
        so that new tools can work with kernels where this feature is not present ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5c5e854b
  6. 08 8月, 2013 3 次提交
    • A
      perf symbols: Add support for reading from /proc/kcore · 8e0cf965
      Adrian Hunter 提交于
      In the absence of vmlinux, perf tools uses kallsyms for symbols.  If the
      user has access, now also map to /proc/kcore.
      
      The dso data_type is now set to either DSO_BINARY_TYPE__KCORE or
      DSO_BINARY_TYPE__GUEST_KCORE as approprite.
      
      This patch breaks the "vmlinux symtab matches kallsyms" test.  That is
      fixed in a following patch.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1375875537-4509-8-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8e0cf965
    • A
      perf tools: Make it possible to read object code from kernel modules · 0131c4ec
      Adrian Hunter 提交于
      The new "object code reading" test shows that it is not possible to read
      object code from kernel modules.  That is because the mappings do not
      map to the dsos.  This patch fixes that.
      
      This involves identifying and flagging relocatable (ELF type ET_REL)
      files (e.g. kernel modules) for symbol adjustment and updating
      map__rip_2objdump() accordingly.  The kmodule parameter of
      dso__load_sym() is taken into use and the module map altered to map to
      the dso.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1375875537-4509-7-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0131c4ec
    • A
      perf tools: Make it possible to read object code from vmlinux · 39b12f78
      Adrian Hunter 提交于
      The new "object code reading" test shows that it is not possible to read
      object code from vmlinux.  That is because the mappings do not map to
      the dso.  This patch fixes that.
      
      A side-effect of changing the kernel map is that the "reloc" offset must
      be taken into account.  As a result of that separate map functions for
      relocation are no longer needed.
      
      Also fixing up the maps to match the symbols no longer makes sense and
      so is not done.
      
      The vmlinux dso data_type is now set to either DSO_BINARY_TYPE__VMLINUX
      or DSO_BINARY_TYPE__GUEST_VMLINUX as approprite, which enables the
      correct file name to be determined by dso__binary_type_file().
      
      This patch breaks the "vmlinux symtab matches kallsyms" test.  That is
      fixed in a following patch.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1375875537-4509-4-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      39b12f78
  7. 28 5月, 2013 1 次提交
  8. 25 1月, 2013 3 次提交
  9. 09 11月, 2012 1 次提交
  10. 08 11月, 2012 1 次提交
    • N
      perf tools: Fix detection of stack area · 1e82574d
      Namhyung Kim 提交于
      Output of /proc/<pid>/maps contains helpful information to anonymous
      mappings like stack, heap, ...  For the case of stack, it can show
      multiple stack area for each thread in the process:
      
        $ cat /proc/$(pidof gnome-shell)/maps | grep stack
        7fe019946000-7fe01a146000 rw-p 00000000 00:00 0          [stack:1624]
        7fe040e32000-7fe041632000 rw-p 00000000 00:00 0          [stack:1451]
        7fe041643000-7fe041e43000 rw-p 00000000 00:00 0          [stack:1450]
        7fe04204b000-7fe04284b000 rw-p 00000000 00:00 0          [stack:1449]
        7fe042a7e000-7fe04327e000 rw-p 00000000 00:00 0          [stack:1446]
        7fe0432ff000-7fe043aff000 rw-p 00000000 00:00 0          [stack:1445]
        7fe043b00000-7fe044300000 rw-p 00000000 00:00 0          [stack:1444]
        7fe044301000-7fe044b01000 rw-p 00000000 00:00 0          [stack:1443]
        7fe044b02000-7fe045302000 rw-p 00000000 00:00 0          [stack:1442]
        7fe045303000-7fe045b03000 rw-p 00000000 00:00 0          [stack:1441]
        7fe045b04000-7fe046304000 rw-p 00000000 00:00 0          [stack:1440]
        7fe046305000-7fe046b05000 rw-p 00000000 00:00 0          [stack:1439]
        7fe046b06000-7fe047306000 rw-p 00000000 00:00 0          [stack:1438]
        7fff4b16f000-7fff4b190000 rw-p 00000000 00:00 0          [stack]
      
      However perf only knew about the main thread's.  Fix it.
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1352273234-28912-4-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1e82574d
  11. 29 10月, 2012 1 次提交
  12. 29 9月, 2012 1 次提交
  13. 20 9月, 2012 1 次提交
  14. 11 9月, 2012 1 次提交
    • J
      perf tools: Back [vdso] DSO with real data · 7dbf4dcf
      Jiri Olsa 提交于
      Storing data for VDSO shared object, because we need it for the post
      unwind processing.
      
      The VDSO shared object is same for all process on a running system, so
      it makes no difference when we store it inside the tracer - perf.
      
      When [vdso] map memory is hit, we retrieve [vdso] DSO image and store it
      into temporary file.
      
      During the build-id processing phase, the [vdso] DSO image is stored in
      build-id db, and build-id reference is made inside perf.data. The
      build-id vdso file object is called '[vdso]'. We don't use temporary
      file name which gets removed when record is finished.
      
      During report phase the vdso build-id object is treated as any other
      build-id DSO object.
      
      Adding following API for vdso object:
      
        bool is_vdso_map(const char *filename)
          - returns true if the filename matches vdso map name
      
        struct dso *vdso__dso_findnew(struct list_head *head)
          - find/create proper vdso DSO object
      
        vdso__exit(void)
          - removes temporary VDSO image if there's any
      
      This change makes backtrace dwarf post unwind possible from [vdso] maps.
      
      Following output is current report of [vdso] sample dwarf backtrace:
      
        # Overhead  Command      Shared Object                         Symbol
        # ........  .......  .................  .............................
        #
            99.52%       ex  [vdso]             [.] 0x00007fff3ace89af
                         |
                         --- 0x7fff3ace89af
      
      Following output is new report of [vdso] sample dwarf backtrace:
      
        # Overhead  Command      Shared Object                         Symbol
        # ........  .......  .................  .............................
        #
            99.52%       ex  [vdso]             [.] 0x00000000000009af
                         |
                         --- 0x7fff3ace89af
                             main
                             __libc_start_main
                             _start
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1347295819-23177-5-git-send-email-jolsa@redhat.com
      [ committer note: s/ALIGN/PERF_ALIGN/g to cope with the android build changes ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7dbf4dcf
  15. 13 8月, 2012 1 次提交
  16. 10 8月, 2012 2 次提交
  17. 25 7月, 2012 3 次提交
    • D
      perf kvm: Limit repetitive guestmount message to once per directory · c80c3c26
      David Ahern 提交于
      After 7ed97ad4 use of the guestmount option without a subdir for *each*
      VM generates an error message for each sample related to that VM. Once
      per VM is enough.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1342826756-64663-7-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c80c3c26
    • D
      perf kvm: Fix bug resolving guest kernel syms · adb5d2a4
      David Ahern 提交于
      Guest kernel symbols are not resolved despite passing the information
      needed to resolve them. e.g.,
      
      perf kvm --guest --guestmount=/tmp/guest-mount record -a -- sleep 1
      perf kvm --guest --guestmount=/tmp/guest-mount report --stdio
      
          36.55%  [guest/11399]  [unknown]         [g] 0xffffffff81600bc8
          33.19%  [guest/10474]  [unknown]         [g] 0x00000000c0116e00
          30.26%  [guest/11094]  [unknown]         [g] 0xffffffff8100a288
          43.69%  [guest/10474]  [unknown]         [g] 0x00000000c0103d90
          37.38%  [guest/11399]  [unknown]         [g] 0xffffffff81600bc8
          12.24%  [guest/11094]  [unknown]         [g] 0xffffffff810aa91d
           6.69%  [guest/11094]  [unknown]         [u] 0x00007fa784d721c3
      
      which is just pathetic.
      
      After a maddening 2 days sifting through perf minutia I found it --
      id_hdr_size is not initialized for guest machines. This shows up on the
      report side as random garbage for the cpu and timestamp, e.g.,
      
      29816 7310572949125804849 0x1ac0 [0x50]: PERF_RECORD_MMAP ...
      
      That messes up the sample sorting such that synthesized guest maps are
      processed last.
      
      With this patch you get a much more helpful report:
      
        12.11%  [guest/11399]  [guest.kernel.kallsyms.11399]  [g] irqtime_account_process_tick
        10.58%  [guest/11399]  [guest.kernel.kallsyms.11399]  [g] run_timer_softirq
         6.95%  [guest/11094]  [guest.kernel.kallsyms.11094]  [g] printk_needs_cpu
         6.50%  [guest/11094]  [guest.kernel.kallsyms.11094]  [g] do_timer
         6.45%  [guest/11399]  [guest.kernel.kallsyms.11399]  [g] idle_balance
         4.90%  [guest/11094]  [guest.kernel.kallsyms.11094]  [g] native_read_tsc
          ...
      
      v2:
      - changed rbtree walk to use rb_first per Namhyung's suggestion
      Tested-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1342826756-64663-5-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      adb5d2a4
    • D
      perf kvm: Set name for VM process in guest machine · 5cd95c2d
      David Ahern 提交于
      COMM events are not generated in the context of a guest machine, so the
      thread name is never set for the VMM process. For example, the qemu-kvm
      name applies to the process in the host machine, not the guest machine.
      So, samples for guest machines are currently displayed as:
      
          99.67%     :5671  [unknown]         [g] 0xffffffff81366b41
      
      where 5671 is the pid of the VMM. With this patch the samples in the guest
      machine are shown as:
      
          18.43%  [guest/5671]  [unknown]           [g] 0xffffffff810d68b7
      Tested-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1342826756-64663-3-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5cd95c2d
  18. 03 7月, 2012 1 次提交
    • D
      perf kvm: Fix segfault with report and mixed guestmount use · 7ed97ad4
      David Ahern 提交于
      Using the guestmount option on record:
          $ perf kvm --guest --host --guestmount=/tmp/guest-mount record -ag
      
      But not the subsequent report:
          $ perf kvm report
      
      causes a SEGFAULT in the usual place:
      (gdb) bt
      0  0x0000000000470356 in machine__mmap_name (self=0x0, bf=0x7fffffffbdb0 " z\370\367\377\177", size=
          4096) at util/map.c:712
      1  0x00000000004453e8 in perf_event__process_kernel_mmap (tool=0x7fffffffde10, event=0x7ffff7f87e38,
          machine=0x0) at util/event.c:550
      2  0x00000000004458c9 in perf_event__process_mmap (tool=0x7fffffffde10, event=0x7ffff7f87e38, sample=
          0x7fffffffd2a0, machine=0x0) at util/event.c:656
      3  0x00000000004733e0 in perf_session_deliver_event (session=0x91aca0, event=0x7ffff7f87e38, sample=
          0x7fffffffd2a0, tool=0x7fffffffde10, file_offset=7736) at util/session.c:979
      ...
      
      The MMAP events in this case already contain the full path to the
      module. No need to require it for the report path to.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1341241977-71535-1-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7ed97ad4
  19. 06 4月, 2012 1 次提交
  20. 31 1月, 2012 2 次提交
  21. 28 11月, 2011 1 次提交
  22. 19 10月, 2011 1 次提交
  23. 30 9月, 2011 2 次提交
  24. 23 1月, 2011 1 次提交
    • A
      perf tools: Fix 64 bit integer format strings · 9486aa38
      Arnaldo Carvalho de Melo 提交于
      Using %L[uxd] has issues in some architectures, like on ppc64.  Fix it
      by making our 64 bit integers typedefs of stdint.h types and using
      PRI[ux]64 like, for instance, git does.
      
      Reported by Denis Kirjanov that provided a patch for one case, I went
      and changed all cases.
      Reported-by: NDenis Kirjanov <dkirjanov@kernel.org>
      Tested-by: NDenis Kirjanov <dkirjanov@kernel.org>
      LKML-Reference: <20110120093246.GA8031@hera.kernel.org>
      Cc: Denis Kirjanov <dkirjanov@kernel.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Pingtian Han <phan@redhat.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9486aa38
  25. 03 8月, 2010 2 次提交
    • A
      perf tools: Don't keep unreferenced maps when unmaps are detected · 0a1eae39
      Arnaldo Carvalho de Melo 提交于
      For a file with:
      
      [root@emilia linux-2.6-tip]# perf report -D -fi allmodconfig-j32.perf.data | grep events:
           TOTAL events:      36933
            MMAP events:       9056
            LOST events:          0
            COMM events:       1702
            EXIT events:       1887
        THROTTLE events:          8
      UNTHROTTLE events:          8
            FORK events:       1894
            READ events:          0
          SAMPLE events:      22378
            ATTR events:          0
      EVENT_TYPE events:          0
      TRACING_DATA events:          0
        BUILD_ID events:          0
      [root@emilia linux-2.6-tip]#
      
      Testing with valgrind and making perf_session__delete() a nop, so that
      we can notice how many maps were actually deleted due to not having any
      samples on it:
      
      ==== HEAP SUMMARY:
      
      Before:
      
      ==10339==     in use at exit: 8,909,997 bytes in 68,690 blocks
      ==10339==   total heap usage: 78,696 allocs, 10,007 frees, 11,925,853 bytes allocated
      
      After:
      
      ==10506==     in use at exit: 8,902,605 bytes in 68,606 blocks
      ==10506==   total heap usage: 78,696 allocs, 10,091 frees, 11,925,853 bytes allocated
      
      I.e. just 84 detected unmaps with no hits out of 9056 for this workload,
      not much, but in some other long running workload this may save more
      bytes.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0a1eae39
    • A
      perf session: Free the ref_reloc_sym memory at the right place · 076c6e45
      Arnaldo Carvalho de Melo 提交于
      Which is at perf_session__destroy_kernel_maps, counterpart to the
      perf_session__create_kernel_maps where the kmap structure is located, just
      after the vmlinux_maps.
      
      Make it also check if the kernel maps were actually created, which may not
      be the case if, for instance, perf_session__new can't complete due to
      permission problems in, for instance, a 'perf report' case, when a
      segfault will take place, that is how this was noticed.
      
      The problem was introduced in d65a458b, thus post .35.
      
      This also adds code to release guest machines as them are also created
      in perf_session__create_kernel_maps, so should be deleted on this newly
      introduced counterpart, perf_session__destroy_kernel_maps.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      076c6e45
  26. 31 7月, 2010 2 次提交
    • A
      perf tools: Release session and symbol resources on exit · d65a458b
      Arnaldo Carvalho de Melo 提交于
      So that we reduce the noise when looking for leaks using tools such as
      valgrind.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d65a458b
    • A
      perf tools: Release thread resources on PERF_RECORD_EXIT · 591765fd
      Arnaldo Carvalho de Melo 提交于
      For long running sessions with many threads with short lifetimes the
      amount of memory that the buildid process takes is too much.
      
      Since we don't have hist_entries that may be pointing to them, we can
      just release the resources associated with each thread when the exit
      (PERF_RECORD_EXIT) event is received.
      
      For normal processing we need to annotate maps with hits, and thus
      hist_entries pointing to it and drop the ones that had none. Will be
      done in a followup patch.
      
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      591765fd
  27. 27 7月, 2010 1 次提交
  28. 10 5月, 2010 1 次提交
    • A
      perf session: Embed the host machine data on perf_session · 1f626bc3
      Arnaldo Carvalho de Melo 提交于
      We have just one host on a given session, and that is the most common
      setup right now, so embed a ->host_machine struct machine instance
      directly in the perf_session class, check if we're looking for it before
      going to the rb_tree.
      
      This also fixes a problem found when we try to process old perf.data
      files where we didn't have MMAP events for the kernel and modules and
      thus don't create the kernel maps, do it in event__preprocess_sample if
      it wasn't already.
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Cc: Frédéric 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: Tom Zanussi <tzanussi@gmail.com>
      Cc: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1f626bc3