1. 27 2月, 2015 1 次提交
    • K
      perf diff: Support for different binaries · 94ba462d
      Kan Liang 提交于
      Currently, the perf diff only works with same binaries. That's because
      it compares the symbol start address. It doesn't work if the perf.data
      comes from different binaries. This patch matches the symbol names.
      
      Actually, perf diff once intended to compare the symbol names.  The
      commit as below can look for a pair by name.
      
      604c5c92 (perf diff: Change the default sort order to "dso,symbol")
      However, at that time, perf diff used a global list of dsos. That means
      the binaries which has same name can only be loaded once. That's a
      problem for comparing different binaries.
      
      For example, we have an old binary and an updated binary. They very
      likely have same name and most of the functions, so only dsos from old
      binary will be loaded. When processing the data from updated binary,
      perf still use the symbol information from old binary. That's wrong.
      
      Then the commit as below used IP to replace symbol name.
      9c443dfd ("perf diff: Fix support for all --sort combinations")
      >From that time, perf diff starts to compare the symbol address.
      
      The global dsos is discarded from a patch in 2010.
      a1645ce1 ("perf: 'perf kvm' tool for monitoring guest performance
      from host")
      However, at that time, perf diff already compared by address. So perf
      diff cannot work for different binaries as well.
      
      This patch actually rolls back the perf diff to original design. The
      document is also changed, so everybody knows the original design is to
      compare the symbol names.
      
      Here are some examples:
      
      The only difference between example_v1.c and example_v2.c is the
      location of f2 and f3. There is no change in behavior, but the previous
      perf diff display the wrong differential profile.
      
      example_v1.c
      noinline void f3(void)
      {
              volatile int i;
              for (i = 0; i < 10000;) {
      
                      if(i%2)
                              i++;
                      else
                              i++;
              }
      }
      
      noinline void f2(void)
      {
              volatile int a = 100, b, c;
              for (b = 0; b < 10000; b++)
                      c = a * b;
      
      }
      
      noinline void f1(void)
      {
                      f2();
                      f3();
      }
      
      int main()
      {
              int i;
              for (i = 0; i < 100000; i++)
                      f1();
      }
      
      example_v2.c
      noinline void f2(void)
      {
              volatile int a = 100, b, c;
              for (b = 0; b < 10000; b++)
                      c = a * b;
      }
      
      noinline void f3(void)
      {
              volatile int i;
              for (i = 0; i < 10000;) {
                      if(i%2)
                              i++;
                      else
                              i++;
              }
      }
      
      noinline void f1(void)
      {
                      f2();
                      f3();
      }
      
      int main()
      {
              int i;
              for (i = 0; i < 100000; i++)
                      f1();
      }
      
      [lk@localhost perf_diff]$ gcc example_v1.c -o example
      [lk@localhost perf_diff]$ perf record -o example_v1.data ./example
      [ perf record: Woken up 4 times to write data ]
      [ perf record: Captured and wrote 0.813 MB example_v1.data (~35522 samples) ]
      
      [lk@localhost perf_diff]$ gcc example_v2.c -o example
      [lk@localhost perf_diff]$ perf record -o example_v2.data ./example
      [ perf record: Woken up 4 times to write data ]
      [ perf record: Captured and wrote 0.824 MB example_v2.data (~36015 samples) ]
      
      Old perf diff result:
      
      [lk@localhost perf_diff]$ perf diff example_v1.data example_v2.data
       Event 'cycles'
       Baseline    Delta  Shared Object     Symbol
       ........  .......  ................  ...............................
      
                           [kernel.vmlinux]  [k] __perf_event_task_sched_out
           0.00%           [kernel.vmlinux]  [k] apic_timer_interrupt
                           [kernel.vmlinux]  [k] idle_cpu
                           [kernel.vmlinux]  [k] intel_pstate_timer_func
                           [kernel.vmlinux]  [k] native_read_msr_safe
           0.00%           [kernel.vmlinux]  [k] native_read_tsc
           0.00%           [kernel.vmlinux]  [k] native_write_msr_safe
                           [kernel.vmlinux]  [k] ntp_tick_length
           0.00%           [kernel.vmlinux]  [k] rb_erase
           0.00%           [kernel.vmlinux]  [k] tick_sched_timer
           0.00%           [kernel.vmlinux]  [k] unmap_single_vma
           0.00%           [kernel.vmlinux]  [k] update_wall_time
           0.00%           example           [.] f1
          46.24%           example           [.] f2
          53.71%   -7.55%  example           [.] f3
                  +53.81%  example           [.] f3
           0.02%           example           [.] main
      
      New perf diff result:
      
      [lk@localhost perf_diff]$ perf diff example_v1.data example_v2.data
                           [kernel.vmlinux]  [k] __perf_event_task_sched_out
           0.00%           [kernel.vmlinux]  [k] apic_timer_interrupt
                           [kernel.vmlinux]  [k] idle_cpu
                           [kernel.vmlinux]  [k] intel_pstate_timer_func
                           [kernel.vmlinux]  [k] native_read_msr_safe
           0.00%           [kernel.vmlinux]  [k] native_read_tsc
           0.00%           [kernel.vmlinux]  [k] native_write_msr_safe
                           [kernel.vmlinux]  [k] ntp_tick_length
           0.00%           [kernel.vmlinux]  [k] rb_erase
           0.00%           [kernel.vmlinux]  [k] tick_sched_timer
           0.00%           [kernel.vmlinux]  [k] unmap_single_vma
           0.00%           [kernel.vmlinux]  [k] update_wall_time
           0.00%           example           [.] f1
          46.24%   -0.08%  example           [.] f2
          53.71%   +0.11%  example           [.] f3
           0.02%           example           [.] main
      Signed-off-by: NKan Liang <kan.liang@intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Acked-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Link: http://lkml.kernel.org/r/1423460384-11645-1-git-send-email-kan.liang@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      94ba462d
  2. 22 1月, 2015 1 次提交
  3. 25 11月, 2014 1 次提交
  4. 19 11月, 2014 1 次提交
    • A
      perf hists: Fix up srcline histogram key formatting · b2d53671
      Arnaldo Carvalho de Melo 提交于
      Problem introduced in:
      
        commit 5b591669 "perf report: Honor column width setting"
      
      Where the left justification signal was after the width, which ended up,
      when the width was, say, 11, always printing:
      
      	%11.11-s
      
      Instead of src:line left justified and limited to 11 chars.
      
      Resulting in a like:
      
          70.93%  %11.11-s  [.] f2                     tcall
      
      When it should instead be:
      
          70.93%  tcall.c:5    [.] f2                     tcall
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-2xnt0vqkoox52etq2qhyetr0@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b2d53671
  5. 29 10月, 2014 7 次提交
  6. 10 10月, 2014 1 次提交
    • A
      perf evsel: Add hists helper · 4ea062ed
      Arnaldo Carvalho de Melo 提交于
      Not all tools need a hists instance per perf_evsel, so lets pave the way
      to remove evsel->hists while leaving a way to access the hists from a
      specially allocated evsel, one that comes with space at the end where
      lives the evsel.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jean Pihet <jean.pihet@linaro.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@kernel.org>
      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-qlktkhe31w4mgtbd84035sr2@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4ea062ed
  7. 18 9月, 2014 1 次提交
    • J
      perf tools: Add +field argument support for --sort option · 1a1c0ffb
      Jiri Olsa 提交于
      Adding support to add field(s) to default sort order via using the '+'
      prefix, like for report:
      
        $ perf report
        Samples: 2K of event 'cycles', Event count (approx.): 882172583
        Overhead  Command  Shared Object        Symbol
           7.39%  swapper  [kernel.kallsyms]    [k] intel_idle
           1.97%  firefox  libpthread-2.17.so   [.] pthread_mutex_lock
           1.39%  firefox  [snd_hda_intel]      [k] azx_get_position
           1.11%  firefox  libpthread-2.17.so   [.] pthread_mutex_unlock
      
        $ perf report -s +cpu
        Samples: 2K of event 'cycles', Event count (approx.): 882172583
        Overhead  Command  Shared Object        Symbol                  CPU
           2.89%  swapper  [kernel.kallsyms]    [k] intel_idle          000
           2.61%  swapper  [kernel.kallsyms]    [k] intel_idle          002
           1.20%  swapper  [kernel.kallsyms]    [k] intel_idle          001
           0.82%  firefox  libpthread-2.17.so   [.] pthread_mutex_lock  002
      
      Works in general for commands using --sort option.
      
      v2 with changes suggested:
        - Use dynamic memory instead static buffer
        - Fix error message typo
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Acked-by: NNamhyung Kim <namhyung@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: Jiri Olsa <jolsa@kernel.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/20140823125948.GA1193@krava.brq.redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1a1c0ffb
  8. 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
  9. 12 8月, 2014 4 次提交
  10. 08 7月, 2014 1 次提交
  11. 09 6月, 2014 1 次提交
    • 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
  12. 04 6月, 2014 2 次提交
    • 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
    • J
      perf tools: Remove elide setup for SORT_MODE__MEMORY mode · 2ec85c62
      Jiri Olsa 提交于
      There's no need to setup elide of sort_dso sort entry again
      with symbol_conf.dso_list list.
      
      The only difference were list names of memory mode data,
      which does not make much sense to me.
      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/1400858147-7155-2-git-send-email-jolsa@kernel.orgSigned-off-by: NJiri Olsa <jolsa@kernel.org>
      2ec85c62
  13. 01 6月, 2014 2 次提交
  14. 21 5月, 2014 9 次提交
  15. 19 12月, 2013 2 次提交
  16. 12 11月, 2013 1 次提交
  17. 04 11月, 2013 3 次提交
  18. 23 10月, 2013 1 次提交