1. 24 4月, 2017 2 次提交
  2. 21 4月, 2017 3 次提交
  3. 20 4月, 2017 19 次提交
  4. 27 3月, 2017 2 次提交
    • M
      perf report: Enable sorting by srcline as key · 5dfa210e
      Milian Wolff 提交于
      Often it is interesting to know how costly a given source line is in
      total. Previously, one had to build these sums manually based on all
      addresses that pointed to the same source line. This patch introduces
      srcline as a sort key, which will do the aggregation for us.
      
      Paired with the recent addition of showing inline frames, this makes
      perf report much more useful for many C++ work loads.
      
      The following shows the new feature in action. First, let's show the
      status quo output when we sort by address. The result contains many hist
      entries that generate the same output:
      
        ~~~~~~~~~~~~~~~~
        $ perf report --stdio --inline -g address
        # Children      Self  Command       Shared Object        Symbol
        # ........  ........  ............  ...................  .........................................
        #
            99.89%    35.34%  cpp-inlining  cpp-inlining         [.] main
                  |
                  |--64.55%--main complex:655
                  |          /home/milian/projects/kdab/rnd/hotspot/tests/test-clients/cpp-inlining/main.cpp:39 (inline)
                  |          /usr/include/c++/6.3.1/complex:664 (inline)
                  |          |
                  |          |--60.31%--hypot +20
                  |          |          |
                  |          |          |--8.52%--__hypot_finite +273
                  |          |          |
                  |          |          |--7.32%--__hypot_finite +411
      ...
                   --35.34%--_start +4194346
                             __libc_start_main +241
                             |
                             |--6.65%--main random.tcc:3326
                             |          /home/milian/projects/kdab/rnd/hotspot/tests/test-clients/cpp-inlining/main.cpp:39 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1809 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1818 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:185 (inline)
                             |
                             |--2.70%--main random.tcc:3326
                             |          /home/milian/projects/kdab/rnd/hotspot/tests/test-clients/cpp-inlining/main.cpp:39 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1809 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1818 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:185 (inline)
                             |
                             |--1.69%--main random.tcc:3326
                             |          /home/milian/projects/kdab/rnd/hotspot/tests/test-clients/cpp-inlining/main.cpp:39 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1809 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1818 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:185 (inline)
        ...
        ~~~~~~~~~~~~~~~~
      
      With this patch and `-g srcline` we instead get the following output:
      
        ~~~~~~~~~~~~~~~~
        $ perf report --stdio --inline -g srcline
        # Children      Self  Command       Shared Object        Symbol
        # ........  ........  ............  ...................  .........................................
        #
            99.89%    35.34%  cpp-inlining  cpp-inlining         [.] main
                  |
                  |--64.55%--main complex:655
                  |          /home/milian/projects/kdab/rnd/hotspot/tests/test-clients/cpp-inlining/main.cpp:39 (inline)
                  |          /usr/include/c++/6.3.1/complex:664 (inline)
                  |          |
                  |          |--64.02%--hypot
                  |          |          |
                  |          |           --59.81%--__hypot_finite
                  |          |
                  |           --0.53%--cabs
                  |
                   --35.34%--_start
                             __libc_start_main
                             |
                             |--12.48%--main random.tcc:3326
                             |          /home/milian/projects/kdab/rnd/hotspot/tests/test-clients/cpp-inlining/main.cpp:39 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1809 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:1818 (inline)
                             |          /usr/include/c++/6.3.1/bits/random.h:185 (inline)
        ...
        ~~~~~~~~~~~~~~~~
      Signed-off-by: NMilian Wolff <milian.wolff@kdab.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Yao Jin <yao.jin@linux.intel.com>
      Link: http://lkml.kernel.org/r/20170318214928.9047-1-milian.wolff@kdab.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5dfa210e
    • J
      perf report: Find the inline stack for a given address · a64489c5
      Jin Yao 提交于
      It would be useful for perf to support a mode to query the inline stack
      for a given callgraph address. This would simplify finding the right
      code in code that does a lot of inlining.
      
      The srcline.c has contained the code which supports to translate the
      address to filename:line_nr. This patch just extends the function to let
      it support getting the inline stacks.
      
      It introduces the inline_list which will store the inline function
      result (filename:line_nr and funcname).
      
      If BFD lib is not supported, the result is only filename:line_nr.
      Signed-off-by: NYao Jin <yao.jin@linux.intel.com>
      Tested-by: NMilian Wolff <milian.wolff@kdab.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Link: http://lkml.kernel.org/r/1490474069-15823-3-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a64489c5
  5. 04 3月, 2017 1 次提交
  6. 01 2月, 2017 1 次提交
  7. 12 1月, 2017 1 次提交
  8. 02 12月, 2016 1 次提交
    • D
      perf tools: Move parse_nsec_time to time-utils.c · c284d669
      David Ahern 提交于
      Code move only; no functional change intended.
      
      Committer notes:
      
      Fix the build on Ubuntu 16.04 x86-64 cross-compiling to S/390, with this
      set of auto-detected features:
      
        ...                         dwarf: [ on  ]
        ...            dwarf_getlocations: [ on  ]
        ...                         glibc: [ on  ]
        ...                          gtk2: [ OFF ]
        ...                      libaudit: [ OFF ]
        ...                        libbfd: [ OFF ]
        ...                        libelf: [ on  ]
        ...                       libnuma: [ OFF ]
        ...        numa_num_possible_cpus: [ OFF ]
        ...                       libperl: [ OFF ]
        ...                     libpython: [ OFF ]
        ...                      libslang: [ OFF ]
        ...                     libcrypto: [ OFF ]
        ...                     libunwind: [ OFF ]
        ...            libdw-dwarf-unwind: [ on  ]
        ...                          zlib: [ on  ]
        ...                          lzma: [ OFF ]
        ...                     get_cpuid: [ OFF ]
        ...                           bpf: [ on  ]
      
      Where it was failing with:
      
          CC       /tmp/build/perf/util/time-utils.o
        util/time-utils.c: In function 'parse_nsec_time':
        util/time-utils.c:17:13: error: implicit declaration of function 'strtoul' [-Werror=implicit-function-declaration]
          time_sec = strtoul(str, &end, 10);
                     ^
        util/time-utils.c:17:2: error: nested extern declaration of 'strtoul' [-Werror=nested-externs]
          time_sec = strtoul(str, &end, 10);
          ^
        util/time-utils.c: In function 'perf_time__parse_str':
        util/time-utils.c:93:2: error: implicit declaration of function 'free' [-Werror=implicit-function-declaration]
          free(str);
          ^
        util/time-utils.c:93:2: error: incompatible implicit declaration of built-in function 'free' [-Werror]
        util/time-utils.c:93:2: note: include '<stdlib.h>' or provide a declaration of 'free'
      
      Do as suggested and add a '#include <stdlib.h>' to get the free() and strtoul()
      declarations and fix the build.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Acked-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1480439746-42695-3-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c284d669
  9. 28 10月, 2016 1 次提交
    • N
      perf tools: Introduce timestamp__scnprintf_usec() · 99620a5d
      Namhyung Kim 提交于
      Joonwoo reported that there's a mismatch between timestamps in script
      and sched commands.  This was because of difference in printing the
      timestamp.  Factor out the code and share it so that they can be in
      sync.  Also I found that sched map has similar problem, fix it too.
      
      Committer notes:
      
      Fixed the max_lat_at bug introduced by Namhyung's original patch, as
      pointed out by Joonwoo, and made it a function following the scnprintf()
      model, i.e. returning the number of bytes formatted, and receiving as
      the first parameter the object from where the data to the formatting is
      obtained, renaming it from:
      
         char *timestamp_in_usec(char *bf, size_t size, u64 timestamp)
      
      to
      
         int timestamp__scnprintf_usec(u64 timestamp, char *bf, size_t size)
      Reported-by: NJoonwoo Park <joonwoop@codeaurora.org>
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20161024020246.14928-3-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      99620a5d
  10. 24 10月, 2016 1 次提交
  11. 24 8月, 2016 1 次提交
  12. 19 7月, 2016 1 次提交
  13. 14 7月, 2016 1 次提交
  14. 13 7月, 2016 3 次提交
  15. 17 5月, 2016 1 次提交
    • A
      perf tools: Separate accounting of contexts and real addresses in a stack trace · a29d5c9b
      Arnaldo Carvalho de Melo 提交于
      The perf_sample->ip_callchain->nr value includes all the entries in the
      ip_callchain->ip[] array, real addresses and PERF_CONTEXT_{KERNEL,USER,etc},
      while what the user expects is that what is in the kernel.perf_event_max_stack
      sysctl or in the upcoming per event perf_event_attr.sample_max_stack knob be
      honoured in terms of IP addresses in the stack trace.
      
      So match the kernel support and validate chain->nr taking into account
      both kernel.perf_event_max_stack and kernel.perf_event_max_contexts_per_stack.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Milian Wolff <milian.wolff@kdab.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Zefan Li <lizefan@huawei.com>
      Link: http://lkml.kernel.org/n/tip-mgx0jpzfdq4uq4abfa40byu0@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a29d5c9b
  16. 10 5月, 2016 1 次提交