1. 25 11月, 2014 1 次提交
  2. 19 11月, 2014 1 次提交
  3. 29 10月, 2014 1 次提交
  4. 15 10月, 2014 1 次提交
  5. 26 9月, 2014 3 次提交
  6. 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
  7. 01 6月, 2014 2 次提交
  8. 05 5月, 2014 1 次提交
  9. 22 4月, 2014 1 次提交
  10. 16 1月, 2014 1 次提交
  11. 20 12月, 2013 1 次提交
  12. 29 10月, 2013 1 次提交
  13. 22 10月, 2013 1 次提交
    • N
      perf callchain: Convert children list to rbtree · e369517c
      Namhyung Kim 提交于
      Current collapse stage has a scalability problem which can be reproduced
      easily with a parallel kernel build.
      
      This is because it needs to traverse every children of callchains
      linearly during the collapse/merge stage.
      
      Converting it to a rbtree reduced the overhead significantly.
      
      On my 400MB perf.data file which recorded with make -j32 kernel build:
      
        $ time perf --no-pager report --stdio > /dev/null
      
      before:
        real	6m22.073s
        user	6m18.683s
        sys	0m0.706s
      
      after:
        real	0m20.780s
        user	0m19.962s
        sys	0m0.689s
      
      During the perf report the overhead on append_chain_children went down
      from 96.69% to 18.16%:
      
        -  18.16%  perf  perf                [.] append_chain_children
           - append_chain_children
              - 77.48% append_chain_children
                 + 69.79% merge_chain_branch
                 - 22.96% append_chain_children
                    + 67.44% merge_chain_branch
                    + 30.15% append_chain_children
                    + 2.41% callchain_append
                 + 7.25% callchain_append
              + 12.26% callchain_append
              + 10.22% merge_chain_branch
        +  11.58%  perf  perf                [.] dso__find_symbol
        +   8.02%  perf  perf                [.] sort__comm_cmp
        +   5.48%  perf  libc-2.17.so        [.] malloc_consolidate
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1381468543-25334-2-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e369517c
  14. 30 8月, 2013 1 次提交
  15. 22 7月, 2013 1 次提交
  16. 12 12月, 2012 1 次提交
  17. 01 9月, 2012 1 次提交
  18. 31 5月, 2012 1 次提交
  19. 28 11月, 2011 1 次提交
  20. 30 6月, 2011 1 次提交
    • S
      perf tools: Add inverted call graph report support. · d797fdc5
      Sam Liao 提交于
      Add "caller/callee" option to support inverted butterfly report,
      in the inverted report (with caller option), the call graph start
      from the callee's ancestor. Users can use such view to catch system's
      performance bottleneck from a sysprof like view. Using this option
      with specified sort order like pid gives us high level view of call
      graph statistics.
      
      Also add "-G" alias for inverted call graph.
      Signed-off-by: NSam Liao <phyomh@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: David Ahern <dsahern@gmail.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      d797fdc5
  21. 30 1月, 2011 1 次提交
  22. 23 1月, 2011 4 次提交
    • F
      perf callchain: Don't give arbitrary gender to callchain tree nodes · 529363b7
      Frederic Weisbecker 提交于
      Some little callchain tree nodes shyly asked me if they can have
      sisters.
      
      How cute!
      
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1294977121-5700-5-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      529363b7
    • F
      perf callchain: Rename register_callchain_param into callchain_register_param · 16537f13
      Frederic Weisbecker 提交于
      To make the callchain API naming more consistent.
      
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1294977121-5700-4-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      16537f13
    • F
      perf callchain: Rename cumul_hits into callchain_cumul_hits · f08c3154
      Frederic Weisbecker 提交于
      That makes the callchain API naming more consistent and
      reduce potential naming clashes.
      
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1294977121-5700-3-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f08c3154
    • F
      perf callchain: Feed callchains into a cursor · 1b3a0e95
      Frederic Weisbecker 提交于
      The callchains are fed with an array of a fixed size.
      As a result we iterate over each callchains three times:
      
      - 1st to resolve symbols
      - 2nd to filter out context boundaries
      - 3rd for the insertion into the tree
      
      This also involves some pairs of memory allocation/deallocation
      everytime we insert a callchain, for the filtered out array of
      addresses and for the array of symbols that comes along.
      
      Instead, feed the callchains through a linked list with persistent
      allocations. It brings several pros like:
      
      - Merge the 1st and 2nd iterations in one. That was possible before
      but in a way that would involve allocating an array slightly taller
      than necessary because we don't know in advance the number of context
      boundaries to filter out.
      
      - Much lesser allocations/deallocations. The linked list keeps
      persistent empty entries for the next usages and is extendable at
      will.
      
      - Makes it easier for multiple sources of callchains to feed a
      stacktrace together. This is deemed to pave the way for cfi based
      callchains wherein traditional frame pointer based kernel
      stacktraces will precede cfi based user ones, producing an overall
      callchain which size is hardly predictable. This requirement
      makes the static array obsolete and makes a linked list based
      iterator a much more flexible fit.
      
      Basic testing on a big perf file containing callchains (~ 176 MB)
      has shown a throughput gain of about 11% with perf report.
      
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1294977121-5700-2-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1b3a0e95
  23. 27 8月, 2010 1 次提交
    • F
      perf: Initialize callchains roots's childen hits · 5225c458
      Frederic Weisbecker 提交于
      Each histogram entry has a callchain root that stores the
      callchain samples. However we forgot to initialize the
      tracking of children hits of these roots, which then got
      random values on their creation.
      
      The root children hits is multiplied by the minimum percentage
      of hits provided by the user, and the result becomes the minimum
      hits expected from children branches. If the random value due
      to the uninitialization is big enough, then this minimum number
      of hits can be huge and eventually filter every children branches.
      
      The end result was invisible callchains. All we need to
      fix this is to initialize the children hits of the root.
      Reported-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: 2.6.32.x-2.6.35.y <stable@kernel.org>
      5225c458
  24. 23 8月, 2010 3 次提交
    • F
      perf: Support for callchains merge · 612d4fd7
      Frederic Weisbecker 提交于
      If we sort the histograms by comm, which is the default,
      we need to merge some of them, typically different thread
      histograms of a same process, or just same comm. But during
      this merge, we forgot to merge callchains.
      
      So imagine we have three threads (tids: 1000, 1001, 1002) that
      belong to comm "foo".
      
      tid 1000 got 100 events
      tid 1001 got 10 events
      tid 1002 got 3 events
      
      Once we merge these histograms to get a per comm result, we'll
      finally get:
      
      "foo" got 113 events
      
      The problem is if we merge 1000 and 1001 histograms into 1002, then
      the end merge result, wrt callchains, will be only callchains that
      belong to 1002.
      This is because we haven't handled callchains in the merge. Only those
      from one of the threads inside a common comm survive.
      
      It means during this merge, we can lose a lot of callchains.
      
      Fix this by implementing callchains merge and apply it on histograms
      that collapse.
      Reported-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      612d4fd7
    • F
      perf: Rename append_callchain into callchain_append · 6cb8e561
      Frederic Weisbecker 提交于
      Do that to start a consistant callchain API namespace.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Christoph Hellwig <hch@infradead.org>
      6cb8e561
    • F
      perf: Keep track of the max depth of a callchain · d2009c51
      Frederic Weisbecker 提交于
      In order to implement callchains collapsing, we need to keep
      track of the maximum depth in a histogram tree of callchains.
      This way we'll avoid allocating an arbitrary temporary buffer
      size on callchain merge time.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Christoph Hellwig <hch@infradead.org>
      d2009c51
  25. 08 7月, 2010 2 次提交
    • F
      perf: Sync callchains with period based hits · 108553e1
      Frederic Weisbecker 提交于
      Hists have their hits increased by the event period. And this
      period based counting is the foundation of all the stats in
      perf report.
      
      But callchains still use the raw number of hits, without taking
      the period into account. So when we compute the percentage,
      absolute based percentages are totally broken, and relative ones
      too in the first parent level. Because we pass the number of events
      muliplied by their period as the total number of hits to the
      callchain filtering, while callchains expect this number to be
      the number of raw hits.
      
      perf report -g graph was simply not working, showing no graph unless
      the min percent was zero. And even there the percentage of the
      branches was always 0. And may be fractal filtering was broken on
      the first branch level too.
      
      flat also was broken, but it was hidden because of other breakages.
      
      Anyway fix this by counting using periods on callchains.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      108553e1
    • F
      perf: Resurrect flat callchains · 97aa1052
      Frederic Weisbecker 提交于
      Initialize the callchain radix tree root correctly.
      
      When we walk through the parents, we must stop after the root, but
      since it wasn't well initialized, its parent pointer was random.
      
      Also the number of hits was random because uninitialized, hence it
      was part of the callchain while the root doesn't contain anything.
      
      This fixes segfaults and percentages followed by empty callchains
      while running:
      
      	perf report -g flat
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: 2.6.31.x-2.6.34.x <stable@kernel.org>
      97aa1052
  26. 05 6月, 2010 1 次提交
    • A
      perf tools: Make event__preprocess_sample parse the sample · 41a37e20
      Arnaldo Carvalho de Melo 提交于
      Simplifying the tools that were using both in sequence and allowing
      upcoming simplifications, such as Arun's patch to sort by cpus.
      
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frédéric 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>
      41a37e20
  27. 20 5月, 2010 1 次提交
    • A
      perf annotate: Use build-ids to find the right DSO · b36f19d5
      Arnaldo Carvalho de Melo 提交于
      We were still using the pathname found on the MMAP event, that could not
      be the one we used when recording, so use the build-id cache for that,
      only falling back to use the pathname in the MMAP event if no build-ids
      are available.
      
      With this we now also are able to do secure, seamless offline annotation.
      
      Example:
      
      [root@doppio linux-2.6-tip]# perf report -g none -v 2> /dev/null | head -10
           8.12%     Xorg  /usr/lib64/libpixman-1.so.0.14.0       0x0000000000026d02 B [.] pixman_rasterize_edges
           4.68%  firefox  /usr/lib64/xulrunner-1.9.1/libxul.so   0x00000000005dbdba B [.] 0x000000005dbdba
           3.70%  swapper  /lib/modules/2.6.34-rc6/build/vmlinux  0xffffffff81022cea ! [k] read_hpet
           2.96%     init  /lib/modules/2.6.34-rc6/build/vmlinux  0xffffffff81022cea ! [k] read_hpet
           2.73%  swapper  /lib/modules/2.6.34-rc6/build/vmlinux  0xffffffff8100a738 ! [k] mwait_idle_with_hints
      [root@doppio linux-2.6-tip]# perf annotate -v pixman_rasterize_edges 2>&1 | grep Executing
      Executing: objdump --start-address=0x000000371ce26670 --stop-address=0x000000371ce2709f -dS /root/.debug/.build-id/bd/6ac5199137aaeb279f864717d8d061477466c1|grep -v /root/.debug/.build-id/bd/6ac5199137aaeb279f864717d8d061477466c1|expand
      [root@doppio linux-2.6-tip]# perf buildid-list | grep libpixman-1.so.0.14.0
      bd6ac5199137aaeb279f864717d8d061477466c1 /usr/lib64/libpixman-1.so.0.14.0
      [root@doppio linux-2.6-tip]#
      Reported-by: NStephane Eranian <eranian@google.com>
      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: 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>
      b36f19d5
  28. 10 5月, 2010 2 次提交
  29. 26 3月, 2010 1 次提交
  30. 23 3月, 2010 1 次提交
    • F
      perf: Fix orphan callchain branches · 301fde27
      Frederic Weisbecker 提交于
      Callchains have markers inside their capture to tell we
      enter a context (kernel, user, ...).
      
      Those are not displayed in the callchains but they are
      incidentally an active part of the radix tree where
      callchains are stored, just like any other address.
      
      If we have the two following callchains:
      
      addr1 -> addr2 -> user context -> addr3
      addr1 -> addr2 -> user context -> addr4
      addr1 -> addr2 -> addr 5
      
      This is pretty common if addr1 and addr2 are part of an
      interrupt path, addr3 and addr4 are user addresses and
      addr5 is a kernel non interrupt path.
      
      This will be stored as follows in the tree:
      
                         addr1
                         addr2
                         /   \
                        /     addr5
                  user context
                     /    \
                   addr3  addr4
      
      But we ignore the context markers in the report, hence
      the addr3 and addr4 will appear as orphan branches:
      
          |--28.30%-- hrtimer_interrupt
          |          smp_apic_timer_interrupt
          |          apic_timer_interrupt
          |          |           <------------- here, no parent!
          |          |          |
          |          |          |--11.11%-- 0x7fae7bccb875
          |          |          |
          |          |          |--11.11%-- 0xffffffffff60013b
          |          |          |
          |          |          |--11.11%-- __pthread_mutex_lock_internal
          |          |          |
          |          |          |--11.11%-- __errno_location
      
      Fix this by removing the context markers when we process the
      callchains to the tree.
      Reported-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      LKML-Reference: <1269274173-20328-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      301fde27