1. 27 3月, 2017 1 次提交
    • J
      perf report: Show inline stack for stdio mode · 0db64dd0
      Jin Yao 提交于
      If the address belongs to an inlined function, the source information
      back to the first non-inlined function will be printed.
      
      For example:
      
      1. Show inlined function name
         perf report --stdio -g function --inline
      
           0.69%     0.00%  inline   ld-2.23.so           [.] dl_main
                  |
                  ---dl_main
                     |
                      --0.56%--_dl_relocate_object
                                _dl_relocate_object (inline)
                                elf_dynamic_do_Rela (inline)
      
      2. Show the file/line information
         perf report --stdio -g address --inline
      
           0.69%     0.00%  inline   ld-2.23.so           [.] _dl_start_user
                  |
                  ---_dl_start_user .:0
                     _dl_start rtld.c:307
                     /build/glibc-GKVZIf/glibc-2.23/elf/rtld.c:413 (inline)
                     _dl_sysdep_start dl-sysdep.c:250
                     |
                      --0.56%--dl_main rtld.c:2076
      
      Committer tests:
      
        # perf record --call-graph dwarf ~/bin/perf stat usleep 1
      
       Performance counter stats for 'usleep 1':
      
                0.443020      task-clock (msec)         #    0.449 CPUs utilized
                       1      context-switches          #    0.002 M/sec
                       0      cpu-migrations            #    0.000 K/sec
                      52      page-faults               #    0.117 M/sec
               1,049,423      cycles                    #    2.369 GHz
                 801,456      instructions              #    0.76  insn per cycle
                 155,609      branches                  #  351.246 M/sec
                   7,026      branch-misses             #    4.52% of all branches
      
             0.000987570 seconds time elapsed
      
        [ perf record: Woken up 2 times to write data ]
        [ perf record: Captured and wrote 0.553 MB perf.data (66 samples) ]
        # perf report --stdio --inline fs__get_mountpoint
        <SNIP>
           1.73%     0.00%  perf     perf           [.] fs__get_mountpoint
                  |
                  ---fs__get_mountpoint
                     fs__get_mountpoint (inline)
                     fs__check_mounts (inline)
                     __statfs
                     entry_SYSCALL_64
                     sys_statfs
                     SYSC_statfs
                     user_statfs
                     user_path_at_empty
                     filename_lookup
                     path_lookupat
                     link_path_walk
                     inode_permission
                     __inode_permission
                     kernfs_iop_permission
                     kernfs_refresh_inode
                     security_inode_notifysecctx
                     selinux_inode_notifysecctx
                     selinux_inode_setsecurity
                     security_context_to_sid
                     security_context_to_sid_core
                     string_to_context_struct
                     symcmp
      Signed-off-by: NYao Jin <yao.jin@linux.intel.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.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-5-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0db64dd0
  2. 13 3月, 2017 1 次提交
  3. 20 2月, 2017 1 次提交
  4. 02 2月, 2017 2 次提交
  5. 21 1月, 2017 1 次提交
  6. 20 1月, 2017 1 次提交
  7. 17 1月, 2017 1 次提交
  8. 16 12月, 2016 1 次提交
    • R
      perf annotate: Fix jump target outside of function address range · e216874c
      Ravi Bangoria 提交于
      If jump target is outside of function range, perf is not handling it
      correctly. Especially when target address is lesser than function start
      address, target offset will be negative. But, target address declared to
      be unsigned, converts negative number into 2's complement. See below
      example. Here target of 'jumpq' instruction at 34cf8 is 34ac0 which is
      lesser than function start address(34cf0).
      
              34ac0 - 34cf0 = -0x230 = 0xfffffffffffffdd0
      
      Objdump output:
      
        0000000000034cf0 <__sigaction>:
        __GI___sigaction():
          34cf0: lea    -0x20(%rdi),%eax
          34cf3: cmp    -bashx1,%eax
          34cf6: jbe    34d00 <__sigaction+0x10>
          34cf8: jmpq   34ac0 <__GI___libc_sigaction>
          34cfd: nopl   (%rax)
          34d00: mov    0x386161(%rip),%rax        # 3bae68 <_DYNAMIC+0x2e8>
          34d07: movl   -bashx16,%fs:(%rax)
          34d0e: mov    -bashxffffffff,%eax
          34d13: retq
      
      perf annotate before applying patch:
      
        __GI___sigaction  /usr/lib64/libc-2.22.so
                 lea    -0x20(%rdi),%eax
                 cmp    -bashx1,%eax
              v  jbe    10
              v  jmpq   fffffffffffffdd0
                 nop
          10:    mov    _DYNAMIC+0x2e8,%rax
                 movl   -bashx16,%fs:(%rax)
                 mov    -bashxffffffff,%eax
                 retq
      
      perf annotate after applying patch:
      
        __GI___sigaction  /usr/lib64/libc-2.22.so
                 lea    -0x20(%rdi),%eax
                 cmp    -bashx1,%eax
              v  jbe    10
              ^  jmpq   34ac0 <__GI___libc_sigaction>
                 nop
          10:    mov    _DYNAMIC+0x2e8,%rax
                 movl   -bashx16,%fs:(%rax)
                 mov    -bashxffffffff,%eax
                 retq
      Signed-off-by: NRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Chris Riyder <chris.ryder@arm.com>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lkml.kernel.org/r/1480953407-7605-3-git-send-email-ravi.bangoria@linux.vnet.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e216874c
  9. 26 11月, 2016 2 次提交
  10. 25 11月, 2016 1 次提交
    • A
      perf annotate: Remove duplicate 'name' field from disasm_line · 75b49202
      Arnaldo Carvalho de Melo 提交于
      The disasm_line::name field is always equal to ins::name, being used
      just to locate the instruction's ins_ops from the per-arch instructions
      table.
      
      Eliminate this duplication, nuking that field and instead make
      ins__find() return an ins_ops, store it in disasm_line::ins.ops, and
      keep just in disasm_line::ins.name what was in disasm_line::name, this
      way we end up not keeping a reference to entries in the per-arch
      instructions table.
      
      This in turn will help supporting multiple ways to manage the per-arch
      instructions table, allowing resorting that array, for instance, when
      the entries will move after references to its addresses were made. The
      same problem is avoided when one grows the array with realloc.
      
      So architectures simply keeping a constant array will work as well as
      architectures building the table using regular expressions or other
      logic that involves resorting the table.
      Reviewed-by: NRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Chris Riyder <chris.ryder@arm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-vr899azvabnw9gtuepuqfd9t@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      75b49202
  11. 18 11月, 2016 1 次提交
    • A
      perf annotate: Start supporting cross arch annotation · 786c1b51
      Arnaldo Carvalho de Melo 提交于
      Introduce a 'struct arch', where arch specific stuff will live, starting
      with objdump's choice of comment delimitation character, that is '#' in
      x86 while a ';' in arm.
      
      This has some bits and pieces from a patch submitted by Ravi.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Chris Riyder <chris.ryder@arm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-f337tzjjcl8vtapgvjxmhrbx@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      786c1b51
  12. 15 11月, 2016 2 次提交
  13. 09 11月, 2016 4 次提交
  14. 25 10月, 2016 1 次提交
  15. 24 10月, 2016 1 次提交
  16. 21 10月, 2016 1 次提交
  17. 13 10月, 2016 1 次提交
  18. 23 9月, 2016 4 次提交
  19. 21 9月, 2016 3 次提交
  20. 14 9月, 2016 2 次提交
  21. 12 9月, 2016 1 次提交
    • N
      perf hists browser: Fix event group display · d9ea48bc
      Namhyung Kim 提交于
      Milian reported that the event group on TUI shows duplicated overhead.
      This was due to a bug on calculating hpp->buf position.  The
      hpp_advance() was called from __hpp__slsmg_color_printf() on TUI but
      it's already called from the hpp__call_print_fn macro in __hpp__fmt().
      The end result is that the print function returns number of bytes it
      printed but the buffer advanced twice of the length.
      
      This is generally not a problem since it doesn't need to access the
      buffer again.  But with event group, overhead needs to be printed
      multiple times and hist_entry__snprintf_alignment() tries to fill the
      space with buffer after it printed.  So it (brokenly) showed the last
      overhead again.
      
      The bug was there from the beginning, but I think it's only revealed
      when the alignment function was added.
      Reported-by: NMilian Wolff <milian.wolff@kdab.com>
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Fixes: 89fee709 ("perf hists: Do column alignment on the format iterator")
      Link: http://lkml.kernel.org/r/20160912061958.16656-2-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d9ea48bc
  22. 05 9月, 2016 1 次提交
  23. 24 8月, 2016 6 次提交