In --stdio we turn off color output when the output is not a tty,
which is not always desirable, for instance, in:
perf annotate | more
the 'more' tool is perfectly capable of processing the escape sequences
for colored output.
Allow using the existing logic for .perfconfig's "color.ui" to be used
from the command line by providing a stdio__config_color() helper, that
will be used by annotate and report in follow up patches.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@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/n/tip-1u4wjdbcc41dxndsb4klpa9y@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
An important information for the napi_poll tracepoint is knowing
the work done (packets processed) by the napi_poll() call. Add
both the work done and budget, as they are related.
Handle trace_napi_poll() param change in dropwatch/drop_monitor
and in python perf script netdev-times.py in backward compat way,
as python fortunately supports optional parameter handling.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Noticed by the build system, that emitted this warning:
Warning: x86_64's syscall_64.tbl differs from kernel
This was due to the wiring up of the recently added preadv2 & pwritev2
syscalls to the compat code, which hadn't been done by the patch
introducing those syscalls: 4babf2c5ef ("x86: wire up preadv2 and
pwritev2").
The patch doing the compat wiring was:
482dd2ef12 ("x86/syscalls: Wire up compat readv2/writev2 syscalls")
This just silences the perf build warning, as compat syscalls still
can't be supported in 'perf trace´ due to limitations in the
raw_syscalls:sys_{enter,exit} tracepoints it relies on.
Reported-by: Ingo Molnar <mingo@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Milian Wolff <milian.wolff@kdab.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-4dm8eoy0wslgtwqdhz64ods0@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Adding initialized arg into unwind__prepare_access to get feedback about
the initialization state.
It's not possible to get it from error code, because we return 0 even in
case we don't recognize dso, which is valid.
The 'initialized' value is used in following patch to speedup
unwind__prepare_access calls logic in fork path.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1467634583-29147-4-git-send-email-jolsa@kernel.org
[ Remove ; after static inline function signatures, fixes build break ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
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: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Masami 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@devbox
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
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: Hemant Kumar <hemant@linux.vnet.ibm.com>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Namhyung 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@devbox
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
'perf probe --del' removes caches when '--cache' is given. Note that
the delete pattern is not the same as for normal events.
If you cached probes with event name, --del "eventname" works as
expected. However, if you skipped it, the cached probes doesn't have
actual event name. In that case --del "probe-desc" is required (wildcard
is acceptable). For example a cache entry has the probe-desc "vfs_read
$params", you can remove it with --del 'vfs_read*'.
-----
# perf probe --cache --list
/[kernel.kallsyms] (1466a0a250b5d0070c6d0f03c5fed30b237970a1):
vfs_read $params
/usr/lib64/libc-2.17.so (c31ffe7942bfd77b2fca8f9bd5709d387a86d3bc):
getaddrinfo $params
# perf probe --cache --del vfs_read\*
Removed cached event: probe:vfs_read
# perf probe --cache --list
/[kernel.kallsyms] (1466a0a250b5d0070c6d0f03c5fed30b237970a1):
/usr/lib64/libc-2.17.so (c31ffe7942bfd77b2fca8f9bd5709d387a86d3bc):
getaddrinfo $params
-----
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.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/146736021651.27797.10250879847070772920.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Staring at annotations of large functions is useless if there's only a
few samples in them. Report the number of samples in the header to make
this easier to determine.
Committer note:
The change amounts to:
- Percent | Source code & Disassembly of perf-vdso.so for cycles:u
------------------------------------------------------------------
+ Percent | Source code & Disassembly of perf-vdso.so for cycles:u (3278 samples)
+--------------------------------------------------------------------------------
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Link: http://lkml.kernel.org/r/20160630082955.GA30921@twins.programming.kicks-ass.net
[ split from a larger patch ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Following commits are going to allow 'perf data convert' to collect not
only samples, but also non-sample events like comm and fork. In this
patch we count non-sample events using c.non_sample_count, and prepare
to print number of both type of events like:
# ~/perf data convert --all --to-ctf ./out.ctf
[ perf data convert: Converted 'perf.data' into CTF data './out.ctf' ]
[ perf data convert: Converted and wrote 0.846 MB (6508 samples, 686 non-samples) ]
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1466767332-114472-5-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Marc reported use of uninitialized memory:
> In commit "403567217d3f perf symbols: Do not read symbols/data from
> device files" a check to uninitialzied memory was added. This leads to
> the following valgrind output:
>
> ==24515== Syscall param stat(file_name) points to uninitialised byte(s)
> ==24515== at 0x75B26D5: _xstat (in /lib/x86_64-linux-gnu/libc-2.22.so)
> ==24515== by 0x4E548D: stat (stat.h:454)
> ==24515== by 0x4E548D: is_regular_file (util.c:687)
> ==24515== by 0x4A5BEE: dso__load (symbol.c:1435)
> ==24515== by 0x4BB1AE: map__load (map.c:289)
> ==24515== by 0x4BB1AE: map__find_symbol (map.c:333)
> ==24515== by 0x4835B3: thread__find_addr_location (event.c:1300)
> ==24515== by 0x4B5342: add_callchain_ip (machine.c:1652)
> ==24515== by 0x4B5342: thread__resolve_callchain_sample (machine.c:1906)
> ==24515== by 0x4B9E7D: thread__resolve_callchain (machine.c:1958)
> ==24515== by 0x441B3E: process_event (builtin-script.c:795)
> ==24515== by 0x441B3E: process_sample_event (builtin-script.c:920)
> ==24515== by 0x4BEE29: perf_evlist__deliver_sample (session.c:1192)
> ==24515== by 0x4BEE29: machines__deliver_event (session.c:1229)
> ==24515== by 0x4BF770: perf_session__deliver_event (session.c:1286)
> ==24515== by 0x4BF770: ordered_events__deliver_event (session.c:114)
> ==24515== by 0x4C1D17: __ordered_events__flush (ordered-events.c:207)
> ==24515== by 0x4C1D17: ordered_events__flush.part.3 (ordered-events.c:274)
> ==24515== by 0x4BF44C: perf_session__process_user_event (session.c:1325)
> ==24515== by 0x4BF44C: perf_session__process_event (session.c:1451)
> ==24515== Address 0x807c6a0 is 0 bytes inside a block of size 4,096 alloc'd
> ==24515== at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==24515== by 0x4A5BCB: dso__load (symbol.c:1421)
> ==24515== by 0x4BB1AE: map__load (map.c:289)
> ==24515== by 0x4BB1AE: map__find_symbol (map.c:333)
> ==24515== by 0x4835B3: thread__find_addr_location (event.c:1300)
> ==24515== by 0x4B5342: add_callchain_ip (machine.c:1652)
> ==24515== by 0x4B5342: thread__resolve_callchain_sample (machine.c:1906)
> ==24515== by 0x4B9E7D: thread__resolve_callchain (machine.c:1958)
> ==24515== by 0x441B3E: process_event (builtin-script.c:795)
> ==24515== by 0x441B3E: process_sample_event (builtin-script.c:920)
> ==24515== by 0x4BEE29: perf_evlist__deliver_sample (session.c:1192)
> ==24515== by 0x4BEE29: machines__deliver_event (session.c:1229)
> ==24515== by 0x4BF770: perf_session__deliver_event (session.c:1286)
> ==24515== by 0x4BF770: ordered_events__deliver_event (session.c:114)
> ==24515== by 0x4C1D17: __ordered_events__flush (ordered-events.c:207)
> ==24515== by 0x4C1D17: ordered_events__flush.part.3 (ordered-events.c:274)
> ==24515== by 0x4BF44C: perf_session__process_user_event (session.c:1325)
> ==24515== by 0x4BF44C: perf_session__process_event (session.c:1451)
> ==24515== by 0x4C0EAC: __perf_session__process_events (session.c:1804)
> ==24515== by 0x4C0EAC: perf_session__process_events (session.c:1858)
The reason was a typo that passed global 'name' variable as the
is_regular_file argument instead dso->long_name.
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: 403567217d ("perf symbols: Do not read symbols/data from device files")
Link: http://lkml.kernel.org/r/1466772025-17471-2-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Add few more triplets based on Fedora and Ubuntu binutils (cross tools).
Before applying patch on x86:
( Install binutils-powerpc64-linux-gnu.x86_64 )
$ perf report -i perf.data.powerpc --vmlinux vmlinux.powerpc \
--objdump powerpc64-linux-gnu-objdump
After applying patch on x86:
$ perf report -i perf.data.powerpc --vmlinux vmlinux.powerpc
I.e. it will find the right objdump from the environment data recorded
in the perf.data file + these triplets.
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Anton Blanchard <anton@ozlabs.org>
Cc: Daniel Axtens <dja@axtens.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Link: http://lkml.kernel.org/r/1466769240-12376-7-git-send-email-ravi.bangoria@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
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: Taeung 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: Arnaldo Carvalho de Melo <acme@redhat.com>
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: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Andi Kleen <ak@linux.intel.com>
Tested-by: Arnaldo 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.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
