1. 27 4月, 2016 1 次提交
  2. 19 4月, 2016 1 次提交
  3. 18 4月, 2016 1 次提交
  4. 15 4月, 2016 1 次提交
    • A
      perf callchain: Start moving away from global per thread cursors · 91d7b2de
      Arnaldo Carvalho de Melo 提交于
      The recent perf_evsel__fprintf_callchain() move to evsel.c added several
      new symbol requirements to the python binding, for instance:
      
        # perf test -v python
        16: Try 'import perf' in python, checking link problems      :
        --- start ---
        test child forked, pid 18030
        Traceback (most recent call last):
          File "<stdin>", line 1, in <module>
        ImportError: /tmp/build/perf/python/perf.so: undefined symbol:
        callchain_cursor
        test child finished with -1
        ---- end ----
        Try 'import perf' in python, checking link problems: FAILED!
        #
      
      This would require linking against callchain.c to access to the global
      callchain_cursor variables.
      
      Since lots of functions already receive as a parameter a
      callchain_cursor struct pointer, make that be the case for some more
      function so that we can start phasing out usage of yet another global
      variable.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-djko3097eyg2rn66v2qcqfvn@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      91d7b2de
  5. 23 3月, 2016 1 次提交
  6. 14 12月, 2015 1 次提交
  7. 11 12月, 2015 1 次提交
    • W
      perf tools: Clear struct machine during machine__init() · 93b0ba3c
      Wang Nan 提交于
      There are so many test cases use stack allocated 'struct machine'.
      Including:
        test__hists_link
        test__hists_filter
        test__mmap_thread_lookup
        test__thread_mg_share
        test__hists_output
        test__hists_cumulate
      
      Also, in non-test code (for example, machine__new_host()) there are
      code use 'malloc()' to alloc struct machine.
      
      These are dangerous operations, cause some tests fail or hung in
      machines__exit(). For example, in
      
       machines__exit ->
         machine__destroy_kernel_maps ->
           map_groups__remove ->
             maps__remove ->
               pthread_rwlock_wrlock
      
      a incorrectly initialized lock causes unintended behavior.
      
      This patch memset(0) that structure in machine__init() to ensure all
      fields in 'struct machine' are initialized to zero.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1449541544-67621-17-git-send-email-wangnan0@huawei.com
      [ Use memset, see 'man bzero' ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      93b0ba3c
  8. 10 12月, 2015 1 次提交
  9. 08 12月, 2015 1 次提交
  10. 27 11月, 2015 2 次提交
    • W
      perf machine: Adjust dso->long_name for offline module · c03d5184
      Wang Nan 提交于
      Something unexpected may happen if copy statically linked perf to a
      production environment:
      
        # ./perf probe -m ./mymodule.ko my_func
        [mymodule] with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
        Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
          Error: Failed to add events.
        # ./perf buildid-cache -a ./mymodule.ko
        # ./perf probe -m ./mymodule.ko my_func
        Added new event:
          probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)
      
        You can now use it in all perf tools, such as:
      
        	perf record -e probe:my_func -aR sleep 1
      
      Where:
      
        # ldd ./perf
       	not a dynamic executable
        # strace -e open ./perf probe -m ./mymodule.ko my_func
        ...
        open("/home/wangnan/kmodule/mymodule.ko", O_RDONLY) = 3
        open("/home/wangnan/kmodule/../lib64/elfutils/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
        ...
        open("/lib64/tls/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
        open("/lib64/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
        open("/usr/lib64/tls/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
        open("/usr/lib64/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
        open("[mymodule]", O_RDONLY)            = -1 ENOENT (No such file or directory)
        open("/home/wangnan/.debug/.build-id/32/6ab42550ef3d24944f53c817533728367effeb", O_RDONLY) = -1 ENOENT (No such file or directory)
        open("[mymodule]", O_RDONLY)            = -1 ENOENT (No such file or directory)
      
      In the above example, probe fails before we put the module into
      buildid-cache. However, user would expect it success in both case
      because perf is able to find probe points actually.
      
      The reason is because perf won't utilize module's full path if it failed
      to open debuginfo. In:
      
           convert_to_probe_trace_events ->
              find_probe_trace_events_from_map ->
                  get_target_map ->
                      kernel_get_module_map ->
                          machine__findnew_module_map ->
                              map_groups__find_by_name
      
      map_groups__find_by_name() is able to find the map of that module, but
      this information is found from /proc/module before it knows the real
      path of the offline module. Therefore, the map->dso->long_name is set to
      something like '[mymodule]', which prevent dso__load() find the real
      path of the module file.
      
      In another aspect, if dso__load() can get the offline module through
      buildid cache, it can read symble table from that ko. Even if debuginfo
      is not available, 'perf probe' can success if the '.symtab' can be
      found.
      
      This patch improves machine__findnew_module_map(): when dso->long_name
      is leading with '[' (doesn't find path of module when parsing
      /proc/modules), fixes it by dso__set_long_name(), so following
      dso__load() is possible to find the symbol table.
      
      This patch won't interfere with buildid matching. Here is the test
      result:
      
        # ./perf probe -m ./mymodule.ko my_func
        Added new event:
          probe:my_func        (on my_func in /home/wangnan/kmodule/mymodule.ko)
      
        You can now use it in all perf tools, such as:
      
        	perf record -e probe:my_func -aR sleep 1
      
        # ./perf probe -d '*'
        Removed event: probe:my_func
        # mv ./mymodule.{ko,.bak}
        # mv ./moduleb.ko mymodule.ko
        # ./perf probe -m ./mymodule.ko my_func
        /home/wangnan/kmodule/mymodule.ko with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
        Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
          Error: Failed to add events.
      
        # ./perf probe -v -m ./mymodule.ko my_func
        probe-definition(0): my_func
        symbol:my_func file:(null) line:0 offset:0 return:0 lazy:(null)
        0 arguments
        Could not open debuginfo. Try to use symbols.
        symsrc__init: build id mismatch for /home/wangnan/kmodule/mymodule.ko.
        /home/wangnan/kmodule/mymodule.ko with build id 326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
        Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
          Error: Failed to add events. Reason: No such file or directory (Code: -2)
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1448510397-187965-1-git-send-email-wangnan0@huawei.com
      [ Renamed adjust_dso_long_name() do dso__adjust_kmod_long_name() ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c03d5184
    • N
      perf callchain: Honor hide_unresolved · b49a8fe5
      Namhyung Kim 提交于
      If user requested to hide unresolved entries, skip unresolved callchains
      as well as hist entries.
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1448521700-32062-3-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b49a8fe5
  11. 20 11月, 2015 5 次提交
    • M
      perf machine: Fix machine__findnew_module_map to put dso · 566c69c3
      Masami Hiramatsu 提交于
      Fix machine__findnew_module_map to drop the reference to the dso because
      it is already referenced by both machine__findnew_module_dso() and
      map__new2().
      
      Refcnt debugger shows:
      
        ==== [1] ====
        Unreclaimed dso: 0x1ffd980
        Refcount +1 => 1 at
          ./perf(dso__new+0x1ff) [0x4a62df]
          ./perf(__dsos__addnew+0x29) [0x4a6e19]
          ./perf() [0x4b8b91]
          ./perf(modules__parse+0xfc) [0x4a9d5c]
          ./perf() [0x4b8460]
          ./perf(machine__create_kernel_maps+0x150) [0x4bb550]
          ./perf(machine__new_host+0xfa) [0x4bb75a]
          ./perf(init_probe_symbol_maps+0x93) [0x506623]
          ./perf() [0x455ffa]
          ./perf(cmd_probe+0x6c) [0x4566bc]
          ./perf() [0x47abc5]
          ./perf(main+0x610) [0x421f90]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f1345a8eaf5]
          ./perf() [0x4220a9]
      
      This map_groups__insert(0x4b8b91) already gets a reference to the new
      dso:
      
        ----
        eu-addr2line -e ./perf -f 0x4b8b91
        map_groups__insert inlined at util/machine.c:586 in
        machine__create_module
        util/map.h:207
        ----
      
      So this dso refcnt will be released when map_groups gets released.
      
        [snip]
        Refcount +1 => 2 at
          ./perf(dso__get+0x34) [0x4a65f4]
          ./perf() [0x4b8b35]
          ./perf(modules__parse+0xfc) [0x4a9d5c]
          ./perf() [0x4b8460]
          ./perf(machine__create_kernel_maps+0x150) [0x4bb550]
          ./perf(machine__new_host+0xfa) [0x4bb75a]
          ./perf(init_probe_symbol_maps+0x93) [0x506623]
          ./perf() [0x455ffa]
          ./perf(cmd_probe+0x6c) [0x4566bc]
          ./perf() [0x47abc5]
          ./perf(main+0x610) [0x421f90]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f1345a8eaf5]
          ./perf() [0x4220a9]
      
      Here, machine__findnew_module_dso(0x4b8b35) gets the dso (and stores it
      in a local variable):
      
        ----
        # eu-addr2line -e ./perf -f 0x4b8b35
        machine__findnew_module_dso inlined at util/machine.c:578 in
        machine__create_module
        util/machine.c:514
        ----
      
        Refcount +1 => 3 at
          ./perf(dso__get+0x34) [0x4a65f4]
          ./perf(map__new2+0x76) [0x4be1c6]
          ./perf() [0x4b8b4f]
          ./perf(modules__parse+0xfc) [0x4a9d5c]
          ./perf() [0x4b8460]
          ./perf(machine__create_kernel_maps+0x150) [0x4bb550]
          ./perf(machine__new_host+0xfa) [0x4bb75a]
          ./perf(init_probe_symbol_maps+0x93) [0x506623]
          ./perf() [0x455ffa]
          ./perf(cmd_probe+0x6c) [0x4566bc]
          ./perf() [0x47abc5]
          ./perf(main+0x610) [0x421f90]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f1345a8eaf5]
          ./perf() [0x4220a9]
      
      But also map__new2() gets the dso which will be put when the map is
      released.
      
      So, we have to drop the constructor reference obtained in
      machine__findnew_module_dso().
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20151118064035.30709.58824.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      566c69c3
    • M
      perf tools: Fix machine__create_kernel_maps to put kernel dso refcount · 1154c957
      Masami Hiramatsu 提交于
      Fix machine__create_kernel_maps() to put kernel dso because the dso has
      been gotten via __machine__create_kernel_maps().
      
      Refcnt debugger shows:
        ==== [0] ====
        Unreclaimed dso: 0x3036ab0
        Refcount +1 => 1 at
          ./perf(dso__new+0x1ff) [0x4a62df]
          ./perf(__dsos__addnew+0x29) [0x4a6e19]
          ./perf(dsos__findnew+0xd1) [0x4a7181]
          ./perf(machine__findnew_kernel+0x27) [0x4a5e17]
          ./perf() [0x4b8cf2]
          ./perf(machine__create_kernel_maps+0x28) [0x4bb428]
          ./perf(machine__new_host+0xfa) [0x4bb74a]
          ./perf(init_probe_symbol_maps+0x93) [0x506613]
          ./perf() [0x455ffa]
          ./perf(cmd_probe+0x6c) [0x4566bc]
          ./perf() [0x47abc5]
          ./perf(main+0x610) [0x421f90]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7ffa6809eaf5]
          ./perf() [0x4220a9]
        [snip]
        Refcount +1 => 2 at
          ./perf(dsos__findnew+0x7e) [0x4a712e]
          ./perf(machine__findnew_kernel+0x27) [0x4a5e17]
          ./perf() [0x4b8cf2]
          ./perf(machine__create_kernel_maps+0x28) [0x4bb428]
          ./perf(machine__new_host+0xfa) [0x4bb74a]
          ./perf(init_probe_symbol_maps+0x93) [0x506613]
          ./perf() [0x455ffa]
          ./perf(cmd_probe+0x6c) [0x4566bc]
          ./perf() [0x47abc5]
          ./perf(main+0x610) [0x421f90]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7ffa6809eaf5]
          ./perf() [0x4220a9]
        [snip]
        Refcount -1 => 1 at
          ./perf(dso__put+0x2f) [0x4a664f]
          ./perf(machine__delete+0xfe) [0x4b93ee]
          ./perf(exit_probe_symbol_maps+0x28) [0x5066b8]
          ./perf() [0x45628a]
          ./perf(cmd_probe+0x6c) [0x4566bc]
          ./perf() [0x47abc5]
          ./perf(main+0x610) [0x421f90]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7ffa6809eaf5]
          ./perf() [0x4220a9]
      
      Actually, dsos__findnew gets the dso before returning it, so the dso
      user (in this case machine__create_kernel_maps) has to put the dso after
      used.
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20151118064033.30709.98954.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1154c957
    • M
      perf machine: Fix to destroy kernel maps when machine exits · ebe9729c
      Masami Hiramatsu 提交于
      Actually machine__exit forgot to call machine__destroy_kernel_maps.
      
      This fixes some memory leaks on map as below.
      
      Without this fix.
        ----
        ./perf probe vfs_read
        Added new event:
          probe:vfs_read       (on vfs_read)
      
        You can now use it in all perf tools, such as:
      
                perf record -e probe:vfs_read -aR sleep 1
      
        REFCNT: BUG: Unreclaimed objects found.
        REFCNT: Total 4 objects are not reclaimed.
           To see all backtraces, rerun with -v option
        ----
      With this fix.
        ----
        ./perf probe vfs_read
        Added new event:
          probe:vfs_read       (on vfs_read)
      
        You can now use it in all perf tools, such as:
      
                perf record -e probe:vfs_read -aR sleep 1
      
        REFCNT: BUG: Unreclaimed objects found.
        REFCNT: Total 2 objects are not reclaimed.
           To see all backtraces, rerun with -v option
        ----
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20151118064024.30709.43577.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ebe9729c
    • M
      perf machine: Fix machine__destroy_kernel_maps to drop vmlinux_maps references · e96e4078
      Masami Hiramatsu 提交于
      Fix machine__destroy_kernel_maps() to drop vmlinux_maps references
      before filling it with NULL.
      
      Refcnt debugger shows
        ==== [1] ====
        Unreclaimed map: 0x36b1070
        Refcount +1 => 1 at
          ./perf(map__new2+0xb5) [0x4bdec5]
          ./perf(machine__create_kernel_maps+0x72) [0x4bb152]
          ./perf(machine__new_host+0xfa) [0x4bb41a]
          ./perf(init_probe_symbol_maps+0x93) [0x5062d3]
          ./perf() [0x455ffa]
          ./perf(cmd_probe+0x6c) [0x4566bc]
          ./perf() [0x47abc5]
          ./perf(main+0x610) [0x421f90]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f1fc9fc4af5]
          ./perf() [0x4220a9]
        Refcount +1 => 2 at
          ./perf(maps__insert+0x9a) [0x4bfd6a]
          ./perf(machine__create_kernel_maps+0xc3) [0x4bb1a3]
          ./perf(machine__new_host+0xfa) [0x4bb41a]
          ./perf(init_probe_symbol_maps+0x93) [0x5062d3]
          ./perf() [0x455ffa]
          ./perf(cmd_probe+0x6c) [0x4566bc]
          ./perf() [0x47abc5]
          ./perf(main+0x610) [0x421f90]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f1fc9fc4af5]
          ./perf() [0x4220a9]
        Refcount -1 => 1 at
          ./perf(map_groups__exit+0x94) [0x4bea74]
          ./perf(machine__delete+0x3d) [0x4b91fd]
          ./perf(exit_probe_symbol_maps+0x28) [0x506378]
          ./perf() [0x45628a]
          ./perf(cmd_probe+0x6c) [0x4566bc]
          ./perf() [0x47abc5]
          ./perf(main+0x610) [0x421f90]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f1fc9fc4af5]
          ./perf() [0x4220a9]
      
      map__new2() returns map with refcnt = 1, and also map_groups__insert
      gets it again in__machine__create_kernel_maps().
      
      machine__destroy_kernel_maps() calls map_groups__remove() to
      decrement the refcnt, but before decrement it again (corresponding
      to map__new2), it makes vmlinux_maps[type] = NULL. And this may
      cause a refcnt leak.
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20151118064022.30709.3897.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e96e4078
    • M
      perf machine: Fix machine__findnew_module_map to put registered map · 9afcb420
      Masami Hiramatsu 提交于
      Fix machine object to drop the reference to the map object after it
      inserted it into machine->kmaps.
      
      refcnt debugger shows what happened:
        ----
        ==== [2] ====
        Unreclaimed map: 0x346f750
        Refcount +1 => 1 at
          ./perf(map__new2+0xb5) [0x4bdea5]
          ./perf() [0x4b8aaf]
          ./perf(modules__parse+0xfc) [0x4a9cbc]
          ./perf() [0x4b83c0]
          ./perf(machine__create_kernel_maps+0x148) [0x4bb208]
          ./perf(machine__new_host+0xfa) [0x4bb3fa]
          ./perf(init_probe_symbol_maps+0x93) [0x5062b3]
          ./perf() [0x455ffa]
          ./perf(cmd_probe+0x6c) [0x4566bc]
          ./perf() [0x47abc5]
          ./perf(main+0x610) [0x421f90]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f5373899af5]
          ./perf() [0x4220a9]
        Refcount +1 => 2 at
          ./perf(maps__insert+0x9a) [0x4bfd4a]
          ./perf() [0x4b8acb]
          ./perf(modules__parse+0xfc) [0x4a9cbc]
          ./perf() [0x4b83c0]
          ./perf(machine__create_kernel_maps+0x148) [0x4bb208]
          ./perf(machine__new_host+0xfa) [0x4bb3fa]
          ./perf(init_probe_symbol_maps+0x93) [0x5062b3]
          ./perf() [0x455ffa]
          ./perf(cmd_probe+0x6c) [0x4566bc]
          ./perf() [0x47abc5]
          ./perf(main+0x610) [0x421f90]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f5373899af5]
          ./perf() [0x4220a9]
        Refcount -1 => 1 at
          ./perf(map_groups__exit+0x94) [0x4bea54]
          ./perf(machine__delete+0x3d) [0x4b91ed]
          ./perf(exit_probe_symbol_maps+0x28) [0x506358]
          ./perf() [0x45628a]
          ./perf(cmd_probe+0x6c) [0x4566bc]
          ./perf() [0x47abc5]
          ./perf(main+0x610) [0x421f90]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f5373899af5]
          ./perf() [0x4220a9]
        ----
      
      This pattern clearly shows that the refcnt of the map is acquired twice
      by map__new2 and maps__insert but released onlu once at
      map_groups__exit, when we purge its maps rbtree.
      
      Since maps__insert already reference counted the map, we have to drop
      the constructor (map__new2) reference count right after inserting it.
      
      These happened in machine__findnew_module_map, as below.
      
        ----
        # eu-addr2line -e ./perf -f 0x4b8aaf
        machine__findnew_module_map inlined at util/machine.c:1046
        in machine__create_module
        util/machine.c:582
        # eu-addr2line -e ./perf -f 0x4b8acb
        map_groups__insert inlined at util/machine.c:585
        in machine__create_module
        util/map.h:208
        ----
      
      (note that both are at util/machine.c:58X which is
       machine__findnew_module_map)
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20151118064020.30709.40499.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9afcb420
  12. 13 11月, 2015 1 次提交
    • A
      perf symbols: Fix dso lookup by long name and missing buildids · e266a753
      Adrian Hunter 提交于
      Commit 4598a0a6 ("perf symbols: Improve DSO long names lookup speed
      with rbtree") Added a tree to lookup dsos by long name.  That tree gets
      corrupted whenever a dso long name is changed because the tree is not
      updated.
      
      One effect of that is buildid-list does not work with the 'with-hits'
      option because dso lookup fails and results in two structs for the same
      dso.  The first has the buildid but no hits, the second has hits but no
      buildid. e.g.
      
      Before:
      
        $ tools/perf/perf record ls
        arch     certs    CREDITS  Documentation  firmware  include
        ipc      Kconfig  lib      Makefile       net       REPORTING-BUGS
        scripts  sound    usr      block          COPYING   crypto
        drivers  fs       init     Kbuild         kernel    MAINTAINERS
        mm       README   samples  security       tools     virt
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.012 MB perf.data (11 samples) ]
        $ tools/perf/perf buildid-list
        574da826c66538a8d9060d393a8866289bd06005 [kernel.kallsyms]
        30c94dc66a1fe95180c3d68d2b89e576d5ae213c /lib/x86_64-linux-gnu/libc-2.19.so
        $ tools/perf/perf buildid-list -H
        574da826c66538a8d9060d393a8866289bd06005 [kernel.kallsyms]
        0000000000000000000000000000000000000000 /lib/x86_64-linux-gnu/libc-2.19.so
      
      After:
      
        $ tools/perf/perf buildid-list -H
        574da826c66538a8d9060d393a8866289bd06005 [kernel.kallsyms]
        30c94dc66a1fe95180c3d68d2b89e576d5ae213c /lib/x86_64-linux-gnu/libc-2.19.so
      
      The fix is to record the root of the tree on the dso so that
      dso__set_long_name() can update the tree when the long name changes.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Douglas Hatch <doug.hatch@hp.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Scott J Norton <scott.norton@hp.com>
      Cc: Waiman Long <Waiman.Long@hp.com>
      Fixes: 4598a0a6 ("perf symbols: Improve DSO long names lookup speed with rbtree")
      Link: http://lkml.kernel.org/r/1447408112-1920-2-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e266a753
  13. 01 10月, 2015 3 次提交
  14. 14 9月, 2015 1 次提交
    • A
      perf machine: Add pointer to sample's environment · 4cde998d
      Arnaldo Carvalho de Melo 提交于
      The 'struct machine' represents the machine where the samples were/are
      being collected, and we also have a 'struct perf_env' with extra details
      about such machine, that we were collecting at 'perf.data' creation time
      but we also needed when no perf.data file is being used, such as in
      'perf top'.
      
      So, get those structs closer together, as they provide a bigger picture
      of the sample's environment.
      
      In 'perf session', when the file argument is NULL, we can assume that
      the tool is sampling the running machine, so point machine->env to
      the global put in place in previous patches, while set it to the
      perf_header.env one when reading from a file.
      
      This paves the way for machine->env to be used in
      perf_event__preprocess_sample to populate addr_location.socket.
      Tested-by: NWang Nan <wangnan0@huawei.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-2ajotl0khscutm68exictoy9@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4cde998d
  15. 20 8月, 2015 1 次提交
  16. 24 7月, 2015 2 次提交
  17. 20 7月, 2015 1 次提交
  18. 02 7月, 2015 1 次提交
  19. 20 6月, 2015 2 次提交
  20. 08 6月, 2015 3 次提交
  21. 07 6月, 2015 1 次提交
    • K
      perf tools: handle PERF_RECORD_LOST_SAMPLES · c4937a91
      Kan Liang 提交于
      This patch modifies the perf tool to handle the new RECORD type,
      PERF_RECORD_LOST_SAMPLES.
      
      The number of lost-sample events is stored in
      .nr_events[PERF_RECORD_LOST_SAMPLES]. The exact number of samples
      which the kernel dropped is stored in total_lost_samples.
      
      When the percentage of dropped samples is greater than 5%, a warning
      is printed.
      
      Here are some examples:
      
      Eg 1, Recording different frequently-occurring events is safe with the
            patch. Only a very low drop rate is associated with such actions.
      
      $ perf record -e '{cycles:p,instructions:p}' -c 20003 --no-time ~/tchain ~/tchain
      
      $ perf report -D | tail
                SAMPLE events:     120243
                 MMAP2 events:          5
          LOST_SAMPLES events:         24
        FINISHED_ROUND events:         15
      cycles:p stats:
                 TOTAL events:      59348
                SAMPLE events:      59348
      instructions:p stats:
                 TOTAL events:      60895
                SAMPLE events:      60895
      
      $ perf report --stdio --group
       # To display the perf.data header info, please use --header/--header-only options.
       #
       #
       # Total Lost Samples: 24
       #
       # Samples: 120K of event 'anon group { cycles:p, instructions:p }'
       # Event count (approx.): 24048600000
       #
       #         Overhead  Command      Shared Object     Symbol
       # ................  ...........  ................
       ..................................
       #
          99.74%  99.86%  tchain_edit  tchain_edit       [.] f3
           0.09%   0.02%  tchain_edit  tchain_edit       [.] f2
           0.04%   0.00%  tchain_edit  [kernel.vmlinux]  [k] ixgbe_read_reg
      
      Eg 2, Recording the same thing multiple times can lead to high drop
            rate, but it is not a useful configuration.
      
      $ perf record -e '{cycles:p,cycles:p}' -c 20003 --no-time ~/tchain
      Warning: Processed 600592 samples and lost 99.73% samples!
      [perf record: Woken up 148 times to write data]
      [perf record: Captured and wrote 36.922 MB perf.data (1206322 samples)]
      [perf record: Woken up 1 times to write data]
      [perf record: Captured and wrote 0.121 MB perf.data (1629 samples)]
      Signed-off-by: NKan Liang <kan.liang@intel.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: acme@infradead.org
      Cc: eranian@google.com
      Link: http://lkml.kernel.org/r/1431285195-14269-9-git-send-email-kan.liang@intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c4937a91
  22. 03 6月, 2015 2 次提交
    • W
      perf tools: Deal with kernel module names in '[]' correctly · 1f121b03
      Wang Nan 提交于
      Before patch ba92732e ('perf kmaps: Check kmaps to make code more
      robust'), 'perf report' and 'perf annotate' will segfault if trace data
      contains kernel module information like this:
      
       # perf report -D -i ./perf.data
       ...
       0 0 0x188 [0x50]: PERF_RECORD_MMAP -1/0: [0xffffffbff1018000(0xf068000) @ 0]: x [test_module]
       ...
      
       # perf report -i ./perf.data --objdump=/path/to/objdump --kallsyms=/path/to/kallsyms
      
       perf: Segmentation fault
       -------- backtrace --------
       /path/to/perf[0x503478]
       /lib64/libc.so.6(+0x3545f)[0x7fb201f3745f]
       /path/to/perf[0x499b56]
       /path/to/perf(dso__load_kallsyms+0x13c)[0x49b56c]
       /path/to/perf(dso__load+0x72e)[0x49c21e]
       /path/to/perf(map__load+0x6e)[0x4ae9ee]
       /path/to/perf(thread__find_addr_map+0x24c)[0x47deec]
       /path/to/perf(perf_event__preprocess_sample+0x88)[0x47e238]
       /path/to/perf[0x43ad02]
       /path/to/perf[0x4b55bc]
       /path/to/perf(ordered_events__flush+0xca)[0x4b57ea]
       /path/to/perf[0x4b1a01]
       /path/to/perf(perf_session__process_events+0x3be)[0x4b428e]
       /path/to/perf(cmd_report+0xf11)[0x43bfc1]
       /path/to/perf[0x474702]
       /path/to/perf(main+0x5f5)[0x42de95]
       /lib64/libc.so.6(__libc_start_main+0xf4)[0x7fb201f23bd4]
       /path/to/perf[0x42dfc4]
      
      This is because __kmod_path__parse treats '[' leading names as kernel
      name instead of names of kernel module.
      
      If perf.data contains build information and the buildid of such modules
      can be found, the dso->kernel of it will be set to DSO_TYPE_KERNEL by
      __event_process_build_id(), not kernel module.
      
      It will then be passed to dso__load() -> dso__load_kernel_sym() ->
      dso__load_kcore() if --kallsyms is provided.
      
      The refered patch adds NULL pointer checker to avoid segfault. However,
      such kernel modules are still processed incorrectly.
      
      This patch fixes __kmod_path__parse, makes it treat names like
      '[test_module]' as kernel modules.
      
      kmod-path.c is also update to reflect the above changes.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Link: http://lkml.kernel.org/r/1433321541-170245-1-git-send-email-wangnan0@huawei.com
      [ Fixed the merged with 0443f36b ("perf machine: Fix the search
        for the kernel DSO on the unified list" ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1f121b03
    • A
      perf machine: Fix the search for the kernel DSO on the unified list · 0443f36b
      Arnaldo Carvalho de Melo 提交于
      When unifying the user_dsos and kernel_dsos a bug was introduced by
      inverting the check for dso->kernel, fix it.
      
      Fixes: 3d39ac53 ("perf machine: No need to have two DSOs lists")
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/n/tip-xnrnq0kams3s2z9ek1wjb506@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0443f36b
  23. 29 5月, 2015 4 次提交
  24. 28 5月, 2015 1 次提交
    • A
      perf tools: Reference count struct map · 84c2cafa
      Arnaldo Carvalho de Melo 提交于
      We have pointers to struct map instances in several places, like in the
      hist_entry instances, so we need a way to know when we can destroy them,
      otherwise we may either keep leaking them or end up referencing deleted
      instances.
      
      Start fixing it by reference counting them.
      
      This patch puts the reference count for struct map in place, replacing
      direct map__delete() calls with map__put() ones and then grabbing a
      reference count when adding it to the maps struct where maps for a
      struct thread are kept.
      
      Next we'll grab reference counts when setting pointers to struct map
      instances, in places like in the hist_entry code.
      
      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: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-wi19xczk0t2a41r1i2chuio5@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      84c2cafa
  25. 27 5月, 2015 1 次提交
    • A
      perf machine: Mark removed threads as such · 0170b14f
      Arnaldo Carvalho de Melo 提交于
      We use:
      
        BUG_ON(!RB_EMPTY_NODE(&thread->rb_node));
      
      in the thread destructor as a debugging check to find out about
      possibly still referenced thread instances being deleted, to do that
      we need to make sure we use RB_CLEAR_NODE() right after rb_erase(),
      i.e. that we use the newly introduced rb_erase_init(), that works
      just like list_del_init().
      
      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: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-4fcqo5ypy1cjjf15ilb0hn78@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0170b14f