1. 23 7月, 2014 1 次提交
  2. 17 7月, 2014 3 次提交
  3. 27 6月, 2014 1 次提交
    • S
      perf tools powerpc: Adjust callchain based on DWARF debug info · a60335ba
      Sukadev Bhattiprolu 提交于
      When saving the callchain on Power, the kernel conservatively saves excess
      entries in the callchain. A few of these entries are needed in some cases
      but not others. We should use the DWARF debug information to determine
      when the entries are  needed.
      
      Eg: the value in the link register (LR) is needed only when it holds the
      return address of a function. At other times it must be ignored.
      
      If the unnecessary entries are not ignored, we end up with duplicate arcs
      in the call-graphs.
      
      Use the DWARF debug information to determine if any callchain entries
      should be ignored when building call-graphs.
      
      Callgraph before the patch:
      
          14.67%          2234  sprintft  libc-2.18.so       [.] __random
                  |
                  --- __random
                     |
                     |--61.12%-- __random
                     |          |
                     |          |--97.15%-- rand
                     |          |          do_my_sprintf
                     |          |          main
                     |          |          generic_start_main.isra.0
                     |          |          __libc_start_main
                     |          |          0x0
                     |          |
                     |           --2.85%-- do_my_sprintf
                     |                     main
                     |                     generic_start_main.isra.0
                     |                     __libc_start_main
                     |                     0x0
                     |
                      --38.88%-- rand
                                |
                                |--94.01%-- rand
                                |          do_my_sprintf
                                |          main
                                |          generic_start_main.isra.0
                                |          __libc_start_main
                                |          0x0
                                |
                                 --5.99%-- do_my_sprintf
                                           main
                                           generic_start_main.isra.0
                                           __libc_start_main
                                           0x0
      
      Callgraph after the patch:
      
          14.67%          2234  sprintft  libc-2.18.so       [.] __random
                  |
                  --- __random
                     |
                     |--95.93%-- rand
                     |          do_my_sprintf
                     |          main
                     |          generic_start_main.isra.0
                     |          __libc_start_main
                     |          0x0
                     |
                      --4.07%-- do_my_sprintf
                                main
                                generic_start_main.isra.0
                                __libc_start_main
                                0x0
      
      TODO:	For split-debug info objects like glibc, we can only determine
      	the call-frame-address only when both .eh_frame and .debug_info
      	sections are available. We should be able to determin the CFA
      	even without the .eh_frame section.
      
      Fix suggested by Anton Blanchard.
      
      Thanks to valuable input on DWARF debug information from Ulrich Weigand.
      Reported-by: NMaynard Johnson <maynard@us.ibm.com>
      Tested-by: NMaynard Johnson <maynard@us.ibm.com>
      Signed-off-by: NSukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/20140625154903.GA29607@us.ibm.comSigned-off-by: NJiri Olsa <jolsa@kernel.org>
      a60335ba
  4. 20 6月, 2014 1 次提交
  5. 09 6月, 2014 1 次提交
  6. 30 4月, 2014 1 次提交
  7. 28 4月, 2014 1 次提交
  8. 19 3月, 2014 2 次提交
  9. 15 3月, 2014 2 次提交
  10. 10 3月, 2014 1 次提交
  11. 18 2月, 2014 3 次提交
  12. 01 2月, 2014 2 次提交
  13. 16 1月, 2014 1 次提交
  14. 13 1月, 2014 1 次提交
  15. 28 12月, 2013 1 次提交
  16. 13 12月, 2013 1 次提交
  17. 11 12月, 2013 4 次提交
  18. 05 12月, 2013 1 次提交
  19. 15 11月, 2013 1 次提交
  20. 13 11月, 2013 1 次提交
  21. 12 11月, 2013 2 次提交
  22. 04 11月, 2013 1 次提交
  23. 22 10月, 2013 1 次提交
    • W
      perf report: Add --max-stack option to limit callchain stack scan · 91e95617
      Waiman Long 提交于
      When callgraph data was included in the perf data file, it may take a
      long time to scan all those data and merge them together especially if
      the stored callchains are long and the perf data file itself is large,
      like a Gbyte or so.
      
      The callchain stack is currently limited to PERF_MAX_STACK_DEPTH (127).
      This is a large value. Usually the callgraph data that developers are
      most interested in are the first few levels, the rests are usually not
      looked at.
      
      This patch adds a new --max-stack option to perf-report to limit the
      depth of callchain stack data to look at to reduce the time it takes for
      perf-report to finish its processing. It trades the presence of trailing
      stack information with faster speed.
      
      The following table shows the elapsed time of doing perf-report on a
      perf.data file of size 985,531,828 bytes.
      
        --max_stack   Elapsed Time    Output data size
        -----------   ------------    ----------------
        not set        88.0s          124,422,651
        64             87.5s          116,303,213
        32             87.2s          112,023,804
        16             86.6s           94,326,380
        8              59.9s           33,697,248
        4              40.7s           10,116,637
        -g none        27.1s            2,555,810
      Signed-off-by: NWaiman Long <Waiman.Long@hp.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Aswin Chandramouleeswaran <aswin@hp.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Scott J Norton <scott.norton@hp.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1382107129-2010-4-git-send-email-Waiman.Long@hp.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      91e95617
  24. 11 10月, 2013 4 次提交
  25. 25 9月, 2013 1 次提交
  26. 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