Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 05 7月, 2016 4 次提交
    • M
      perf buildid-cache: Scan and import user SDT events to probe cache · 6430a94e
      由 Masami Hiramatsu 提交于 
      perf buildid-cache --add <binary> scans given binary and add
the SDT events to probe cache. "sdt_" prefix is appended for
all SDT providers to avoid event-name clash with other pre-defined
events. It is possible to use the cached SDT events as other cached
events, via perf probe --add "sdt_<provider>:<event>=<event>".

e.g.
  ----
  # perf buildid-cache --add /lib/libc-2.17.so
  # perf probe --cache --list | head -n 5
  /usr/lib/libc-2.17.so (a6fb821bdf53660eb2c29f778757aef294d3d392):
  sdt_libc:setjmp=setjmp
  sdt_libc:longjmp=longjmp
  sdt_libc:longjmp_target=longjmp_target
  sdt_libc:memory_heap_new=memory_heap_new
  # perf probe -x /usr/lib/libc-2.17.so \
    -a sdt_libc:memory_heap_new=memory_heap_new
  Added new event:
    sdt_libc:memory_heap_new (on memory_heap_new
   in /usr/lib/libc-2.17.so)

  You can now use it in all perf tools, such as:

          perf record -e sdt_libc:memory_heap_new -aR sleep 1

  # perf probe -l
    sdt_libc:memory_heap_new (on new_heap+183 in /usr/lib/libc-2.17.so)
  ----

Note that SDT event entries in probe-cache file is somewhat different
from normal cached events. Normal one starts with "#", but SDTs are
starting with "%".
Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/146736025058.27797.13043265488541434502.stgit@devboxSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6430a94e
    • M
      perf probe: Add group name support · 8d993d96
      由 Masami Hiramatsu 提交于 
      Allow user to set group name for adding new event.  Note that user must
ensure that the group name doesn't conflict with existing group name
carefully.

E.g. Existing group name can conflict with other events.  Especially,
using the group name reserved for kernel modules can hide kernel
embedded events when loading modules.
Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/146736024091.27797.9471545190066268995.stgit@devboxSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8d993d96
    • H
      perf sdt: ELF support for SDT · 060fa0c7
      由 Hemant Kumar 提交于 
      This patch serves the initial support to identify and list SDT events in
binaries.  When programs containing SDT markers are compiled, gcc with
the help of assembler directives identifies them and places them in the
section ".note.stapsdt".

To find these markers from the binaries, one needs to traverse through
this section and parse the relevant details like the name, type and
location of the marker. Also, the original location could be skewed due
to the effect of prelinking. If that is the case, the locations need to
be adjusted.

The functions in this patch open a given ELF, find out the SDT section,
parse the relevant details, adjust the location (if necessary) and
populate them in a list.

A typical note entry in ".note.stapsdt" section is as follows :

                                 |--nhdr.n_namesz--|
                ------------------------------------
                |      nhdr      |     "stapsdt"   |
        -----   |----------------------------------|
         |      |  <location>       <base_address> |
         |      |  <semaphore>                     |
nhdr.n_descsize |  "provider_name"   "note_name"   |
         |      |   <args>                         |
        -----   |----------------------------------|
                |      nhdr      |     "stapsdt"   |
                |...

The above shows an excerpt from the section ".note.stapsdt".  'nhdr' is
a structure which has the note name size (n_namesz), note description
size (n_desc_sz) and note type (n_type).

So, in order to parse the note note info, we need nhdr to tell us where
to start from.  As can be seen from <sys/sdt.h>, the name of the SDT
notes given is "stapsdt".  But this is not the identifier of the note.

After that, we go to description of the note to find out its location, the
address of the ".stapsdt.base" section and the semaphore address.
Then, we find the provider name and the SDT marker name and then follow the
arguments.
Signed-off-by: NHemant Kumar <hemant@linux.vnet.ibm.com>
Reviewed-by: NMasami Hiramatsu <mhiramat@kernel.org>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/146736022628.27797.1201368329092908163.stgit@devboxSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      060fa0c7
    • A
      perf build: Add feature detection for libelf's elf_getshdrstrndx() · 2492c465
      由 Arnaldo Carvalho de Melo 提交于 
      That appeared after 0.140, and will be used in the SDT code, so, to
avoid bisection break on older systems, add a feature detection and
provide a stub with a pr_debug() to keep it building.

Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/n/tip-80y0eldgweorqnwha9rvfxjr@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2492c465
  3. 01 7月, 2016 10 次提交
  5. 30 6月, 2016 2 次提交
  7. 29 6月, 2016 1 次提交
  9. 28 6月, 2016 15 次提交
  11. 27 6月, 2016 2 次提交
  13. 24 6月, 2016 5 次提交
    • T
      perf config: Reimplement show_config() using config_set__for_each · 4a35b349
      由 Taeung Song 提交于 
      Recently config_set__for_each got added.  In order to let show_config()
be short and clear, rewrite this function using it.
Signed-off-by: NTaeung Song <treeze.taeung@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1466691272-24117-4-git-send-email-treeze.taeung@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4a35b349
    • T
      perf config: Introduce new init() and exit() · 8a0a9c7e
      由 Taeung Song 提交于 
      Many sub-commands use perf_config() but everytime perf_config() is
called, perf_config() always read config files.  (i.e. user config
'~/.perfconfig' and system config '$(sysconfdir)/perfconfig')

But it is better to use the config set that already contains all config
key-value pairs to avoid this repetitive work reading the config files
in perf_config(). (the config set mean a static variable 'config_set')

In other words, if new perf_config__init() is called, only first time
'config_set' is initialized collecting all configs from the config
files.  And then we could use new perf_config() like old perf_config().
When a sub-command finished, free the config set by perf_config__exit()
at run_builtin().

If we do, 'config_set' can be reused wherever perf_config() is called
and a feature of old perf_config() is the same as new perf_config() work
without the repetitive work that read the config files.

In summary, in order to use features about configuration,
we can call the functions at perf.c and other source files as below.

    # initialize a config set
    perf_config__init()

    # configure actual variables from a config set
    perf_config()

    # eliminate allocated config set
    perf_config__exit()

    # destroy existing config set and initialize a new config set.
    perf_config__refresh()
Signed-off-by: NTaeung Song <treeze.taeung@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1466691272-24117-3-git-send-email-treeze.taeung@gmail.com
[ 'init' counterpart is 'exit', not 'finish' ]
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8a0a9c7e
    • A
      perf script: Add callindent option · e216708d
      由 Adrian Hunter 提交于 
      Based on patches from Andi Kleen.

When printing PT instruction traces with perf script it is rather useful
to see some indentation for the call tree. This patch adds a new
callindent field to perf script that prints spaces for the function call
stack depth.

We already have code to track the function call stack for PT, that we
can reuse with minor modifications.

The resulting output is not quite as nice as ftrace yet, but a lot
better than what was there before.

Note there are some corner cases when the thread stack gets code
confused and prints incorrect indentation. Even with that it is fairly
useful.

When displaying kernel code traces it is recommended to run as root, as
otherwise perf doesn't understand the kernel addresses properly, and may
not reset the call stack correctly on kernel boundaries.

Example output:

	sudo perf-with-kcore record eg2 -a -e intel_pt// -- sleep 1
	sudo perf-with-kcore script eg2 --ns -F callindent,time,comm,pid,sym,ip,addr,flags,cpu --itrace=cre | less
	...
         swapper     0 [000]  5830.389116586:   call        irq_exit                                                     ffffffff8104d620 smp_call_function_single_interrupt+0x30 => ffffffff8107e720 irq_exit
         swapper     0 [000]  5830.389116586:   call            idle_cpu                                                 ffffffff8107e769 irq_exit+0x49 => ffffffff810a3970 idle_cpu
         swapper     0 [000]  5830.389116586:   return          idle_cpu                                                 ffffffff810a39b7 idle_cpu+0x47 => ffffffff8107e76e irq_exit
         swapper     0 [000]  5830.389116586:   call            tick_nohz_irq_exit                                       ffffffff8107e7bd irq_exit+0x9d => ffffffff810f2fc0 tick_nohz_irq_exit
         swapper     0 [000]  5830.389116919:   call                __tick_nohz_idle_enter                               ffffffff810f2fe0 tick_nohz_irq_exit+0x20 => ffffffff810f28d0 __tick_nohz_idle_enter
         swapper     0 [000]  5830.389116919:   call                    ktime_get                                        ffffffff810f28f1 __tick_nohz_idle_enter+0x21 => ffffffff810e9ec0 ktime_get
         swapper     0 [000]  5830.389116919:   call                        read_tsc                                     ffffffff810e9ef6 ktime_get+0x36 => ffffffff81035070 read_tsc
         swapper     0 [000]  5830.389116919:   return                      read_tsc                                     ffffffff81035084 read_tsc+0x14 => ffffffff810e9efc ktime_get
         swapper     0 [000]  5830.389116919:   return                  ktime_get                                        ffffffff810e9f46 ktime_get+0x86 => ffffffff810f28f6 __tick_nohz_idle_enter
         swapper     0 [000]  5830.389116919:   call                    sched_clock_idle_sleep_event                     ffffffff810f290b __tick_nohz_idle_enter+0x3b => ffffffff810a7380 sched_clock_idle_sleep_event
         swapper     0 [000]  5830.389116919:   call                        sched_clock_cpu                              ffffffff810a738b sched_clock_idle_sleep_event+0xb => ffffffff810a72e0 sched_clock_cpu
         swapper     0 [000]  5830.389116919:   call                            sched_clock                              ffffffff810a734d sched_clock_cpu+0x6d => ffffffff81035750 sched_clock
         swapper     0 [000]  5830.389116919:   call                                native_sched_clock                   ffffffff81035754 sched_clock+0x4 => ffffffff81035640 native_sched_clock
         swapper     0 [000]  5830.389116919:   return                              native_sched_clock                   ffffffff8103568c native_sched_clock+0x4c => ffffffff81035759 sched_clock
         swapper     0 [000]  5830.389116919:   return                          sched_clock                              ffffffff8103575c sched_clock+0xc => ffffffff810a7352 sched_clock_cpu
         swapper     0 [000]  5830.389116919:   return                      sched_clock_cpu                              ffffffff810a7356 sched_clock_cpu+0x76 => ffffffff810a7390 sched_clock_idle_sleep_event
         swapper     0 [000]  5830.389116919:   return                  sched_clock_idle_sleep_event                     ffffffff810a7391 sched_clock_idle_sleep_event+0x11 => ffffffff810f2910 __tick_nohz_idle_enter
	...
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NAndi Kleen <ak@linux.intel.com>
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1466689258-28493-4-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e216708d
    • A
      perf auxtrace: Add option to feed branches to the thread stack · 50f73637
      由 Adrian Hunter 提交于 
      In preparation for using the thread stack to print an indent
representing the stack depth in perf script, add an option to tell
decoders to feed branches to the thread stack. Add support for that
option to Intel PT and Intel BTS.

The advantage of using the decoder to feed the thread stack is that it
happens before branch filtering and so can be used with different itrace
options (e.g. it still works when only showing calls, even though the
thread stack needs to see calls and returns). Also it does not conflict
with using the thread stack to get callchains.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NAndi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1466689258-28493-3-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      50f73637
    • A
      perf script: Print sample flags more nicely · 055cd33d
      由 Adrian Hunter 提交于 
      The flags field is synthesized and may have a value when Instruction
Trace decoding. The flags are "bcrosyiABEx" which stand for branch,
call, return, conditional, system, asynchronous, interrupt, transaction
abort, trace begin, trace end, and in transaction, respectively.

Change the display so that known combinations of flags are printed more
nicely e.g.: "call" for "bc", "return" for "br", "jcc" for "bo", "jmp"
for "b", "int" for "bci", "iret" for "bri", "syscall" for "bcs",
"sysret" for "brs", "async" for "by", "hw int" for "bcyi", "tx abrt" for
"bA", "tr strt" for "bB", "tr end" for "bE".

However the "x" flag will be displayed separately in those cases e.g.
"jcc (x)" for a condition branch within a transaction.

Example:

    perf record -e intel_pt//u ls
    perf script --ns -F comm,cpu,pid,tid,time,ip,addr,sym,dso,symoff,flags
    ...
    ls  3689/3689  [001]  2062.020965237:   jcc          7f06a958847a _dl_sysdep_start+0xfa (/lib/x86_64-linux-gnu/ld-2.19.so) =>     7f06a9588450 _dl_sysdep_start+0xd0 (/lib/x86_64-linux-gnu/ld-2.19.so)
    ls  3689/3689  [001]  2062.020965237:   jmp          7f06a9588461 _dl_sysdep_start+0xe1 (/lib/x86_64-linux-gnu/ld-2.19.so) =>     7f06a95885a0 _dl_sysdep_start+0x220 (/lib/x86_64-linux-gnu/ld-2.19.so)
    ls  3689/3689  [001]  2062.020965237:   jmp          7f06a95885a4 _dl_sysdep_start+0x224 (/lib/x86_64-linux-gnu/ld-2.19.so) =>     7f06a9588470 _dl_sysdep_start+0xf0 (/lib/x86_64-linux-gnu/ld-2.19.so)
    ls  3689/3689  [001]  2062.020965904:   call         7f06a95884c3 _dl_sysdep_start+0x143 (/lib/x86_64-linux-gnu/ld-2.19.so) =>     7f06a9589140 brk+0x0 (/lib/x86_64-linux-gnu/ld-2.19.so)
    ls  3689/3689  [001]  2062.020965904:   syscall      7f06a958914a brk+0xa (/lib/x86_64-linux-gnu/ld-2.19.so) =>                0 [unknown] ([unknown])
    ls  3689/3689  [001]  2062.020966237:   tr strt                 0 [unknown] ([unknown]) =>     7f06a958914c brk+0xc (/lib/x86_64-linux-gnu/ld-2.19.so)
    ls  3689/3689  [001]  2062.020966237:   return       7f06a9589165 brk+0x25 (/lib/x86_64-linux-gnu/ld-2.19.so) =>     7f06a95884c8 _dl_sysdep_start+0x148 (/lib/x86_64-linux-gnu/ld-2.19.so)
    ls  3689/3689  [001]  2062.020966237:   jcc          7f06a95884d7 _dl_sysdep_start+0x157 (/lib/x86_64-linux-gnu/ld-2.19.so) =>     7f06a95885f0 _dl_sysdep_start+0x270 (/lib/x86_64-linux-gnu/ld-2.19.so)
    ls  3689/3689  [001]  2062.020966237:   call         7f06a95885f0 _dl_sysdep_start+0x270 (/lib/x86_64-linux-gnu/ld-2.19.so) =>     7f06a958ac50 strlen+0x0 (/lib/x86_64-linux-gnu/ld-2.19.so)
    ls  3689/3689  [001]  2062.020966237:   jcc          7f06a958ac6e strlen+0x1e (/lib/x86_64-linux-gnu/ld-2.19.so) =>     7f06a958ac60 strlen+0x10 (/lib/x86_64-linux-gnu/ld-2.19.so)
    ...
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NAndi Kleen <ak@linux.intel.com>
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1466689258-28493-2-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      055cd33d
  15. 23 6月, 2016 1 次提交