1. 07 11月, 2013 1 次提交
  2. 06 11月, 2013 1 次提交
  3. 04 11月, 2013 1 次提交
  4. 24 10月, 2013 1 次提交
  5. 22 10月, 2013 4 次提交
  6. 21 10月, 2013 2 次提交
  7. 09 10月, 2013 1 次提交
  8. 05 10月, 2013 2 次提交
  9. 04 10月, 2013 1 次提交
  10. 19 9月, 2013 1 次提交
  11. 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
  12. 10 9月, 2013 1 次提交
    • A
      perf trace: Handle perf.data files with no tracepoints · ccf53eac
      Arnaldo Carvalho de Melo 提交于
      Before:
      
        perf trace -i perf.data
        Segmentation fault (core dumped)
        #
      
      After:
      
       # perf trace -i perf.data
       Data file does not have raw_syscalls:sys_enter events
       #
      
      When there are no tracepoints in a perf.data file the struct pevent
      that contains the list of tracepoints that will be used to lookup the
      tracepoint id by name will not be populated, causing a NULL deref.
      
      And we don't need to do all that dance to look at pevents for an entry
      with a slighly different name to then lookup the tracepoint by its id on
      the evlist, just use the perf_evlist__find_tracepoint_by_name() routine,
      that will find the tracepoint, if present.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-egcm21k1e6gcyxpcgjxtmsq3@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ccf53eac
  13. 06 9月, 2013 1 次提交
    • J
      perf session: Separate progress bar update when processing events · 526fd8d4
      Jiri Olsa 提交于
      Currently when processing events in the __perf_session__process_events
      function we update a progress bar based on the file_size. During the
      same processing we update the progress bar from within
      flush_sample_queue which is based on number of samples count.
      
      Having 2 different based updates is causing the progress bar to jump
      heavily back and forth giving not much usefull info.
      
      Fixing this by keeping only __perf_session__process_events based
      progress bar update. And turning on flush_sample_queue progress bar
      update only for final flushing.
      
      This reduces the number of time the progress bar update function is
      called and it significantly reduces the loading time for TUI, where the
      progress bar update takes quite a lot of time.
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20130905091449.GC1100@krava.brq.redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      526fd8d4
  14. 03 9月, 2013 1 次提交
    • D
      perf tools: Fix symbol offset computation for some dsos · 0b8c25d9
      David Ahern 提交于
      For some dsos (e.g., libc, libpthread, kernel modules) the symbol offset
      is huge. e.g.,
      
      qemu-kvm 17238/17242 [007] 762235.640311:
          ffffffff816288a1 __schedule+0x451 ([kernel.kallsyms])
          ffffffff81629609 schedule+0x29 ([kernel.kallsyms])
          ffffffffa00a6ded kvm_vcpu_block+0xffffffffa00a106d (/lib/modules/3.11.0-rc1+/kernel/arch/x86/kvm/kvm.ko)
          ffffffffa00bae6b kvm_arch_vcpu_ioctl_run+0xffffffffa00a118b (/lib/modules/3.11.0-rc1+/kernel/arch/x86/kvm/kvm.ko)
          ffffffffa00a4d7a kvm_vcpu_ioctl+0xffffffffa00a141a (/lib/modules/3.11.0-rc1+/kernel/arch/x86/kvm/kvm.ko)
          ffffffff811a7bdb do_vfs_ioctl+0x8b ([kernel.kallsyms])
          ffffffff811a80c1 sys_ioctl+0x91 ([kernel.kallsyms])
          ffffffff81633182 system_call+0x72 ([kernel.kallsyms])
              7f882a97af27 __GI___ioctl+0x7f882a891007 (/lib64/libc-2.14.90.so)
                 100000002 [unknown] ([unknown])
      
      It seems to be maps with a non-0 start. Taking that into account the
      offsets are correct:
      
      qemu-kvm 17238/17242 [007] 762235.640311:
          ffffffff816288a1 __schedule+0x451 ([kernel.kallsyms])
          ffffffff81629609 schedule+0x29 ([kernel.kallsyms])
          ffffffffa00a6ded kvm_vcpu_block+0x6d (/lib/modules/3.11.0-rc1+/kernel/arch/x86/kvm/kvm.ko)
          ffffffffa00bae6b kvm_arch_vcpu_ioctl_run+0x18b (/lib/modules/3.11.0-rc1+/kernel/arch/x86/kvm/kvm.ko)
          ffffffffa00a4d7a kvm_vcpu_ioctl+0x41a (/lib/modules/3.11.0-rc1+/kernel/arch/x86/kvm/kvm.ko)
          ffffffff811a7bdb do_vfs_ioctl+0x8b ([kernel.kallsyms])
          ffffffff811a80c1 sys_ioctl+0x91 ([kernel.kallsyms])
          ffffffff81633182 system_call+0x72 ([kernel.kallsyms])
              7f882a97af27 __GI___ioctl+0x7 (/lib64/libc-2.14.90.so)
                 100000002 [unknown] ([unknown])
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Link: http://lkml.kernel.org/r/1375026512-45826-1-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0b8c25d9
  15. 30 8月, 2013 3 次提交
  16. 29 8月, 2013 1 次提交
  17. 12 8月, 2013 5 次提交
  18. 08 8月, 2013 5 次提交
  19. 18 7月, 2013 1 次提交
  20. 16 7月, 2013 1 次提交
  21. 13 7月, 2013 4 次提交
  22. 01 4月, 2013 1 次提交