1. 11 3月, 2016 1 次提交
  2. 08 3月, 2016 1 次提交
  3. 26 2月, 2016 1 次提交
  4. 25 2月, 2016 2 次提交
  5. 23 2月, 2016 2 次提交
  6. 26 1月, 2016 2 次提交
  7. 08 1月, 2016 1 次提交
  8. 07 1月, 2016 5 次提交
  9. 18 12月, 2015 1 次提交
  10. 07 10月, 2015 1 次提交
  11. 06 10月, 2015 1 次提交
  12. 14 9月, 2015 2 次提交
  13. 11 8月, 2015 1 次提交
    • A
      perf report: Add support for srcfile sort key · 31191a85
      Andi Kleen 提交于
      In some cases it's useful to characterize samples by file. This is
      useful to get a higher level categorization, for example to map cost to
      subsystems.
      
      Add a srcfile sort key to perf report. It builds on top of the existing
      srcline support.
      
      Commiter notes:
      
      E.g.:
      
        # perf record -F 10000 usleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.016 MB perf.data (13 samples) ]
        [root@zoo ~]# perf report -s srcfile --stdio
        # Total Lost Samples: 0
        #
        # Samples: 13  of event 'cycles'
        # Event count (approx.): 869878
        #
        # Overhead  Source File
        # ........  ...........
            60.99%  .
            20.62%  paravirt.h
            14.23%  rmap.c
             4.04%  signal.c
             0.11%  msr.h
      
        #
      
      The first line is collecting all the files for which srcfiles couldn't somehow
      get resolved to:
      
        # perf report -s srcfile,dso --stdio
        # Total Lost Samples: 0
        #
        # Samples: 13  of event 'cycles'
        # Event count (approx.): 869878
        #
        # Overhead  Source File  Shared Object
        # ........  ...........  ................
            40.97%  .            ld-2.20.so
            20.62%  paravirt.h   [kernel.vmlinux]
            20.02%  .            libc-2.20.so
            14.23%  rmap.c       [kernel.vmlinux]
             4.04%  signal.c     [kernel.vmlinux]
             0.11%  msr.h        [kernel.vmlinux]
      
        #
      
      XXX: Investigate why that is not resolving on Fedora 21, Andi says he hasn't
           seen this on Fedora 22.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/1438988064-21834-1-git-send-email-andi@firstfloor.org
      [ Added column length update, from 0e65bdb3f90f ('perf hists: Update the column width for the "srcline" sort key') ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      31191a85
  14. 07 8月, 2015 1 次提交
  15. 06 5月, 2015 3 次提交
  16. 29 4月, 2015 2 次提交
  17. 24 3月, 2015 1 次提交
  18. 18 3月, 2015 1 次提交
  19. 24 8月, 2014 1 次提交
    • J
      perf tools: Add +field argument support for --field option · 2f3f9bcf
      Jiri Olsa 提交于
      Adding support to add field(s) to default field order via using the '+'
      prefix, like for report:
      
        $ perf report
        Samples: 10  of event 'cycles', Event count (approx.): 4463799
        Overhead  Command  Shared Object      Symbol
          32.40%  ls       [kernel.kallsyms]  [k] filemap_fault
          28.19%  ls       [kernel.kallsyms]  [k] get_page_from_freelist
          23.38%  ls       [kernel.kallsyms]  [k] enqueue_entity
          15.04%  ls       [kernel.kallsyms]  [k] mmap_region
      
        $ perf report -F +period,sample
        Samples: 10  of event 'cycles', Event count (approx.): 4463799
        Overhead        Period       Samples  Command  Shared Object      Symbol
          32.40%       1446493             1  ls       [kernel.kallsyms]  [k] filemap_fault
          28.19%       1258486             1  ls       [kernel.kallsyms]  [k] get_page_from_freelist
          23.38%       1043754             1  ls       [kernel.kallsyms]  [k] enqueue_entity
          15.04%        671160             1  ls       [kernel.kallsyms]  [k] mmap_region
      
      Works in general for commands using --field option.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jean Pihet <jean.pihet@linaro.org>
      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/1408715919-25990-2-git-send-email-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2f3f9bcf
  20. 09 6月, 2014 2 次提交
    • D
      perf tools: Add dcacheline sort · 9b32ba71
      Don Zickus 提交于
      In perf's 'mem-mode', one can get access to a whole bunch of details specific to a
      particular sample instruction.  A bunch of those details relate to the data
      address.
      
      One interesting thing you can do with data addresses is to convert them into a unique
      cacheline they belong too.  Organizing these data cachelines into similar groups and sorting
      them can reveal cache contention.
      
      This patch creates an alogorithm based on various sample details that can help group
      entries together into data cachelines and allows 'perf report' to sort on it.
      
      The algorithm relies on having proper mmap2 support in the kernel to help determine
      if the memory map the data address belongs to is private to a pid or globally shared.
      
      The alogortithm is as follows:
      
      o group cpumodes together
      o group entries with discovered maps together
      o sort on major, minor, inode and inode generation numbers
      o if userspace anon, then sort on pid
      o sort on cachelines based on data addresses
      
      The 'dcacheline' sort option in 'perf report' only works in 'mem-mode'.
      
      Sample output:
      
       #
       # Samples: 206  of event 'cpu/mem-loads/pp'
       # Total weight : 2534
       # Sort order   : dcacheline,pid
       #
       # Overhead       Samples                                                          Data Cacheline       Command:  Pid
       # ........  ............  ......................................................................  ..................
       #
          13.22%             1  [k] 0xffff88042f08ebc0                                                       swapper:    0
           9.27%             1  [k] 0xffff88082e8cea80                                                       swapper:    0
           3.59%             2  [k] 0xffffffff819ba180                                                       swapper:    0
           0.32%             1  [k] arch_trigger_all_cpu_backtrace_handler_na.23901+0xffffffffffffffe0       swapper:    0
           0.32%             1  [k] timekeeper_seq+0xfffffffffffffff8                                        swapper:    0
      
      Note:  Added a '+1' to symlen size in hists__calc_col_len to prevent the next column
      from prematurely tabbing over and mis-aligning.  Not sure what the problem is.
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Link: http://lkml.kernel.org/r/1401208087-181977-8-git-send-email-dzickus@redhat.comSigned-off-by: NJiri Olsa <jolsa@kernel.org>
      9b32ba71
    • D
      perf tools: Add cpumode to struct hist_entry · 7365be55
      Don Zickus 提交于
      The next patch needs to sort on cpumode, so add it to hist_entry to be tracked.
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Link: http://lkml.kernel.org/r/1401208087-181977-6-git-send-email-dzickus@redhat.comSigned-off-by: NJiri Olsa <jolsa@kernel.org>
      7365be55
  21. 04 6月, 2014 1 次提交
    • J
      perf tools: Move elide bool into perf_hpp_fmt struct · f2998422
      Jiri Olsa 提交于
      After output/sort fields refactoring, it's expensive
      to check the elide bool in its current location inside
      the 'struct sort_entry'.
      
      The perf_hpp__should_skip function gets highly noticable in
      workloads with high number of output/sort fields, like for:
      
        $ perf report -i perf-test.data -F overhead,sample,period,comm,pid,dso,symbol,cpu --stdio
      
      Performance report:
         9.70%  perf  [.] perf_hpp__should_skip
      
      Moving the elide bool into the 'struct perf_hpp_fmt', which
      makes the perf_hpp__should_skip just single struct read.
      
      Got speedup of around 22% for my test perf.data workload.
      The change should not harm any other workload types.
      
      Performance counter stats for (10 runs):
        before:
         358,319,732,626      cycles                    ( +-  0.55% )
         467,129,581,515      instructions              #    1.30  insns per cycle          ( +-  0.00% )
      
           150.943975206 seconds time elapsed           ( +-  0.62% )
      
        now:
         278,785,972,990      cycles                    ( +-  0.12% )
         370,146,797,640      instructions              #    1.33  insns per cycle          ( +-  0.00% )
      
           116.416670507 seconds time elapsed           ( +-  0.31% )
      Acked-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Namhyung Kim <namhyung@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/20140601142622.GA9131@krava.brq.redhat.comSigned-off-by: NJiri Olsa <jolsa@kernel.org>
      f2998422
  22. 01 6月, 2014 2 次提交
  23. 21 5月, 2014 4 次提交
  24. 07 11月, 2013 1 次提交