License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2017-04-18 13:46:11 +00:00
|
|
|
#include <errno.h>
|
2017-04-17 18:23:08 +00:00
|
|
|
#include <inttypes.h>
|
2019-07-30 13:58:41 +00:00
|
|
|
#include <linux/err.h>
|
2009-12-11 23:24:02 +00:00
|
|
|
#include <linux/kernel.h>
|
2019-07-04 14:32:27 +00:00
|
|
|
#include <linux/zalloc.h>
|
2017-03-16 16:41:59 +00:00
|
|
|
#include <api/fs/fs.h>
|
2009-12-11 23:24:02 +00:00
|
|
|
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
#include <byteswap.h>
|
2009-12-11 23:24:02 +00:00
|
|
|
#include <unistd.h>
|
|
|
|
#include <sys/types.h>
|
2010-05-18 21:29:23 +00:00
|
|
|
#include <sys/mman.h>
|
2019-07-21 11:24:30 +00:00
|
|
|
#include <perf/cpumap.h>
|
2009-12-11 23:24:02 +00:00
|
|
|
|
2019-08-30 18:09:54 +00:00
|
|
|
#include "map_symbol.h"
|
|
|
|
#include "branch.h"
|
2019-08-29 18:56:40 +00:00
|
|
|
#include "debug.h"
|
2011-03-06 00:40:06 +00:00
|
|
|
#include "evlist.h"
|
|
|
|
#include "evsel.h"
|
2017-04-25 18:45:35 +00:00
|
|
|
#include "memswap.h"
|
2019-01-27 12:42:37 +00:00
|
|
|
#include "map.h"
|
2019-01-27 23:03:34 +00:00
|
|
|
#include "symbol.h"
|
2009-12-11 23:24:02 +00:00
|
|
|
#include "session.h"
|
2011-11-28 10:30:20 +00:00
|
|
|
#include "tool.h"
|
2012-08-07 13:20:45 +00:00
|
|
|
#include "perf_regs.h"
|
2014-06-12 07:50:11 +00:00
|
|
|
#include "asm/bug.h"
|
2015-04-09 15:53:48 +00:00
|
|
|
#include "auxtrace.h"
|
2017-04-20 00:34:35 +00:00
|
|
|
#include "thread.h"
|
2015-05-29 13:33:30 +00:00
|
|
|
#include "thread-stack.h"
|
2019-01-17 13:37:17 +00:00
|
|
|
#include "sample-raw.h"
|
2015-10-25 14:51:42 +00:00
|
|
|
#include "stat.h"
|
2019-08-30 14:28:14 +00:00
|
|
|
#include "ui/progress.h"
|
2019-08-29 18:20:59 +00:00
|
|
|
#include "../perf.h"
|
2018-11-06 21:07:10 +00:00
|
|
|
#include "arch/common.h"
|
2020-12-16 18:57:57 +00:00
|
|
|
#include "units.h"
|
2019-09-03 13:56:06 +00:00
|
|
|
#include <internal/lib.h>
|
2009-12-11 23:24:02 +00:00
|
|
|
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
#ifdef HAVE_ZSTD_SUPPORT
|
|
|
|
static int perf_session__process_compressed_event(struct perf_session *session,
|
|
|
|
union perf_event *event, u64 file_offset)
|
|
|
|
{
|
|
|
|
void *src;
|
|
|
|
size_t decomp_size, src_size;
|
|
|
|
u64 decomp_last_rem = 0;
|
2019-07-09 14:48:14 +00:00
|
|
|
size_t mmap_len, decomp_len = session->header.env.comp_mmap_len;
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
struct decomp *decomp, *decomp_last = session->decomp_last;
|
|
|
|
|
2019-07-09 14:48:14 +00:00
|
|
|
if (decomp_last) {
|
|
|
|
decomp_last_rem = decomp_last->size - decomp_last->head;
|
|
|
|
decomp_len += decomp_last_rem;
|
|
|
|
}
|
|
|
|
|
|
|
|
mmap_len = sizeof(struct decomp) + decomp_len;
|
|
|
|
decomp = mmap(NULL, mmap_len, PROT_READ|PROT_WRITE,
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
|
|
|
|
if (decomp == MAP_FAILED) {
|
|
|
|
pr_err("Couldn't allocate memory for decompression\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
decomp->file_pos = file_offset;
|
2019-07-09 14:48:14 +00:00
|
|
|
decomp->mmap_len = mmap_len;
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
decomp->head = 0;
|
|
|
|
|
2019-07-09 14:48:14 +00:00
|
|
|
if (decomp_last_rem) {
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
memcpy(decomp->data, &(decomp_last->data[decomp_last->head]), decomp_last_rem);
|
|
|
|
decomp->size = decomp_last_rem;
|
|
|
|
}
|
|
|
|
|
2019-08-28 13:57:16 +00:00
|
|
|
src = (void *)event + sizeof(struct perf_record_compressed);
|
|
|
|
src_size = event->pack.header.size - sizeof(struct perf_record_compressed);
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
|
|
|
|
decomp_size = zstd_decompress_stream(&(session->zstd_data), src, src_size,
|
|
|
|
&(decomp->data[decomp_last_rem]), decomp_len - decomp_last_rem);
|
|
|
|
if (!decomp_size) {
|
2019-07-09 14:48:14 +00:00
|
|
|
munmap(decomp, mmap_len);
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
pr_err("Couldn't decompress data\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
decomp->size += decomp_size;
|
|
|
|
|
|
|
|
if (session->decomp == NULL) {
|
|
|
|
session->decomp = decomp;
|
|
|
|
session->decomp_last = decomp;
|
|
|
|
} else {
|
|
|
|
session->decomp_last->next = decomp;
|
|
|
|
session->decomp_last = decomp;
|
|
|
|
}
|
|
|
|
|
2020-08-20 21:25:01 +00:00
|
|
|
pr_debug("decomp (B): %zd to %zd\n", src_size, decomp_size);
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#else /* !HAVE_ZSTD_SUPPORT */
|
|
|
|
#define perf_session__process_compressed_event perf_session__process_compressed_event_stub
|
|
|
|
#endif
|
|
|
|
|
2015-04-09 15:53:48 +00:00
|
|
|
static int perf_session__deliver_event(struct perf_session *session,
|
|
|
|
union perf_event *event,
|
|
|
|
struct perf_tool *tool,
|
|
|
|
u64 file_offset);
|
2015-03-03 15:20:38 +00:00
|
|
|
|
2013-11-05 18:32:36 +00:00
|
|
|
static int perf_session__open(struct perf_session *session)
|
2009-12-11 23:24:02 +00:00
|
|
|
{
|
2017-01-23 21:07:59 +00:00
|
|
|
struct perf_data *data = session->data;
|
2010-04-02 04:59:15 +00:00
|
|
|
|
2013-11-05 18:32:36 +00:00
|
|
|
if (perf_session__read_header(session) < 0) {
|
2015-11-09 20:12:03 +00:00
|
|
|
pr_err("incompatible file format (rerun with -v to learn more)\n");
|
2013-10-15 14:27:33 +00:00
|
|
|
return -1;
|
2009-12-11 23:24:02 +00:00
|
|
|
}
|
|
|
|
|
2017-01-23 21:07:59 +00:00
|
|
|
if (perf_data__is_pipe(data))
|
2013-10-15 14:27:34 +00:00
|
|
|
return 0;
|
|
|
|
|
2015-11-05 14:40:47 +00:00
|
|
|
if (perf_header__has_feat(&session->header, HEADER_STAT))
|
|
|
|
return 0;
|
|
|
|
|
2020-06-17 12:24:21 +00:00
|
|
|
if (!evlist__valid_sample_type(session->evlist)) {
|
2015-11-09 20:12:03 +00:00
|
|
|
pr_err("non matching sample_type\n");
|
2013-10-15 14:27:33 +00:00
|
|
|
return -1;
|
2011-06-02 14:04:54 +00:00
|
|
|
}
|
|
|
|
|
2020-06-17 12:29:48 +00:00
|
|
|
if (!evlist__valid_sample_id_all(session->evlist)) {
|
2015-11-09 20:12:03 +00:00
|
|
|
pr_err("non matching sample_id_all\n");
|
2013-10-15 14:27:33 +00:00
|
|
|
return -1;
|
2011-06-02 14:04:54 +00:00
|
|
|
}
|
|
|
|
|
2020-11-30 18:07:49 +00:00
|
|
|
if (!evlist__valid_read_format(session->evlist)) {
|
2015-11-09 20:12:03 +00:00
|
|
|
pr_err("non matching read_format\n");
|
2013-10-15 14:27:33 +00:00
|
|
|
return -1;
|
2012-10-10 15:38:13 +00:00
|
|
|
}
|
|
|
|
|
2009-12-11 23:24:02 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-08-01 22:31:00 +00:00
|
|
|
void perf_session__set_id_hdr_size(struct perf_session *session)
|
2010-12-02 12:25:28 +00:00
|
|
|
{
|
2020-11-30 18:13:12 +00:00
|
|
|
u16 id_hdr_size = evlist__id_hdr_size(session->evlist);
|
2012-08-01 22:31:00 +00:00
|
|
|
|
|
|
|
machines__set_id_hdr_size(&session->machines, id_hdr_size);
|
2010-12-02 12:25:28 +00:00
|
|
|
}
|
|
|
|
|
2013-11-05 18:32:36 +00:00
|
|
|
int perf_session__create_kernel_maps(struct perf_session *session)
|
2010-04-19 05:32:50 +00:00
|
|
|
{
|
2013-11-05 18:32:36 +00:00
|
|
|
int ret = machine__create_kernel_maps(&session->machines.host);
|
2010-04-19 05:32:50 +00:00
|
|
|
|
|
|
|
if (ret >= 0)
|
2013-11-05 18:32:36 +00:00
|
|
|
ret = machines__create_guest_kernel_maps(&session->machines);
|
2010-04-19 05:32:50 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-11-05 18:32:36 +00:00
|
|
|
static void perf_session__destroy_kernel_maps(struct perf_session *session)
|
perf session: Free the ref_reloc_sym memory at the right place
Which is at perf_session__destroy_kernel_maps, counterpart to the
perf_session__create_kernel_maps where the kmap structure is located, just
after the vmlinux_maps.
Make it also check if the kernel maps were actually created, which may not
be the case if, for instance, perf_session__new can't complete due to
permission problems in, for instance, a 'perf report' case, when a
segfault will take place, that is how this was noticed.
The problem was introduced in d65a458, thus post .35.
This also adds code to release guest machines as them are also created
in perf_session__create_kernel_maps, so should be deleted on this newly
introduced counterpart, perf_session__destroy_kernel_maps.
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-08-02 21:18:28 +00:00
|
|
|
{
|
2013-11-05 18:32:36 +00:00
|
|
|
machines__destroy_kernel_maps(&session->machines);
|
perf session: Free the ref_reloc_sym memory at the right place
Which is at perf_session__destroy_kernel_maps, counterpart to the
perf_session__create_kernel_maps where the kmap structure is located, just
after the vmlinux_maps.
Make it also check if the kernel maps were actually created, which may not
be the case if, for instance, perf_session__new can't complete due to
permission problems in, for instance, a 'perf report' case, when a
segfault will take place, that is how this was noticed.
The problem was introduced in d65a458, thus post .35.
This also adds code to release guest machines as them are also created
in perf_session__create_kernel_maps, so should be deleted on this newly
introduced counterpart, perf_session__destroy_kernel_maps.
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-08-02 21:18:28 +00:00
|
|
|
}
|
|
|
|
|
2014-07-31 06:00:45 +00:00
|
|
|
static bool perf_session__has_comm_exec(struct perf_session *session)
|
|
|
|
{
|
2019-07-21 11:23:51 +00:00
|
|
|
struct evsel *evsel;
|
2014-07-31 06:00:45 +00:00
|
|
|
|
2016-06-23 14:26:15 +00:00
|
|
|
evlist__for_each_entry(session->evlist, evsel) {
|
2019-07-21 11:24:29 +00:00
|
|
|
if (evsel->core.attr.comm_exec)
|
2014-07-31 06:00:45 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void perf_session__set_comm_exec(struct perf_session *session)
|
|
|
|
{
|
|
|
|
bool comm_exec = perf_session__has_comm_exec(session);
|
|
|
|
|
|
|
|
machines__set_comm_exec(&session->machines, comm_exec);
|
|
|
|
}
|
|
|
|
|
2015-03-03 15:20:38 +00:00
|
|
|
static int ordered_events__deliver_event(struct ordered_events *oe,
|
2015-03-31 15:48:16 +00:00
|
|
|
struct ordered_event *event)
|
2015-03-03 15:20:38 +00:00
|
|
|
{
|
2015-03-31 15:48:16 +00:00
|
|
|
struct perf_session *session = container_of(oe, struct perf_session,
|
|
|
|
ordered_events);
|
|
|
|
|
perf tools: Optimize sample parsing for ordered events
Currently when using ordered events we parse the sample twice (the
perf_evlist__parse_sample function). Once before we queue the sample for
sorting:
perf_session__process_event
perf_evlist__parse_sample(sample)
perf_session__queue_event(sample.time)
And then when we deliver the sorted sample:
ordered_events__deliver_event
perf_evlist__parse_sample
perf_session__deliver_event
We can skip the initial full sample parsing by using
perf_evlist__parse_sample_timestamp function, which got introduced
earlier. The new path looks like:
perf_session__process_event
perf_evlist__parse_sample_timestamp
perf_session__queue_event
ordered_events__deliver_event
perf_session__deliver_event
perf_evlist__parse_sample
It saves some instructions and is slightly faster:
Before:
Performance counter stats for './perf.old report --stdio' (5 runs):
64,396,007,225 cycles:u ( +- 0.97% )
105,882,112,735 instructions:u # 1.64 insn per cycle ( +- 0.00% )
21.618103465 seconds time elapsed ( +- 1.12% )
After:
Performance counter stats for './perf report --stdio' (5 runs):
60,567,807,182 cycles:u ( +- 0.40% )
104,853,333,514 instructions:u # 1.73 insn per cycle ( +- 0.00% )
20.168895243 seconds time elapsed ( +- 0.32% )
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-cjp2tuk0qkjs9dxzlpmm34ua@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-08-03 11:21:14 +00:00
|
|
|
return perf_session__deliver_event(session, event->event,
|
2015-04-09 15:53:48 +00:00
|
|
|
session->tool, event->file_offset);
|
2015-03-03 15:20:38 +00:00
|
|
|
}
|
|
|
|
|
2017-01-23 21:07:59 +00:00
|
|
|
struct perf_session *perf_session__new(struct perf_data *data,
|
2013-10-15 14:27:32 +00:00
|
|
|
bool repipe, struct perf_tool *tool)
|
2009-12-11 23:24:02 +00:00
|
|
|
{
|
2019-08-22 07:20:49 +00:00
|
|
|
int ret = -ENOMEM;
|
2013-11-05 18:32:36 +00:00
|
|
|
struct perf_session *session = zalloc(sizeof(*session));
|
2011-12-07 09:02:54 +00:00
|
|
|
|
2013-11-05 18:32:36 +00:00
|
|
|
if (!session)
|
2009-12-11 23:24:02 +00:00
|
|
|
goto out;
|
|
|
|
|
2013-11-05 18:32:36 +00:00
|
|
|
session->repipe = repipe;
|
2015-03-31 15:48:16 +00:00
|
|
|
session->tool = tool;
|
2015-04-30 14:37:25 +00:00
|
|
|
INIT_LIST_HEAD(&session->auxtrace_index);
|
2013-11-05 18:32:36 +00:00
|
|
|
machines__init(&session->machines);
|
2018-11-07 15:58:36 +00:00
|
|
|
ordered_events__init(&session->ordered_events,
|
|
|
|
ordered_events__deliver_event, NULL);
|
2009-12-11 23:24:02 +00:00
|
|
|
|
2019-03-12 05:30:42 +00:00
|
|
|
perf_env__init(&session->header.env);
|
2017-01-23 21:07:59 +00:00
|
|
|
if (data) {
|
2019-08-22 07:20:49 +00:00
|
|
|
ret = perf_data__open(data);
|
|
|
|
if (ret < 0)
|
2010-01-27 23:05:52 +00:00
|
|
|
goto out_delete;
|
2013-10-15 14:27:33 +00:00
|
|
|
|
2017-01-23 21:07:59 +00:00
|
|
|
session->data = data;
|
2013-10-15 14:27:33 +00:00
|
|
|
|
2017-01-23 21:07:59 +00:00
|
|
|
if (perf_data__is_read(data)) {
|
2019-08-22 07:20:49 +00:00
|
|
|
ret = perf_session__open(session);
|
|
|
|
if (ret < 0)
|
2019-03-05 15:25:35 +00:00
|
|
|
goto out_delete;
|
2013-10-15 14:27:33 +00:00
|
|
|
|
2017-04-10 20:14:30 +00:00
|
|
|
/*
|
|
|
|
* set session attributes that are present in perf.data
|
|
|
|
* but not in pipe-mode.
|
|
|
|
*/
|
2017-01-23 21:07:59 +00:00
|
|
|
if (!data->is_pipe) {
|
2017-04-10 20:14:30 +00:00
|
|
|
perf_session__set_id_hdr_size(session);
|
|
|
|
perf_session__set_comm_exec(session);
|
|
|
|
}
|
2019-01-17 13:37:17 +00:00
|
|
|
|
2020-11-30 18:11:10 +00:00
|
|
|
evlist__init_trace_event_sample_raw(session->evlist);
|
2019-03-08 13:47:35 +00:00
|
|
|
|
|
|
|
/* Open the directory data. */
|
2019-08-22 07:20:49 +00:00
|
|
|
if (data->is_dir) {
|
|
|
|
ret = perf_data__open_dir(data);
|
2019-10-07 11:20:27 +00:00
|
|
|
if (ret)
|
|
|
|
goto out_delete;
|
2019-08-22 07:20:49 +00:00
|
|
|
}
|
perf record: Put a copy of kcore into the perf.data directory
Add a new 'perf record' option '--kcore' which will put a copy of
/proc/kcore, kallsyms and modules into a perf.data directory. Note, that
without the --kcore option, output goes to a file as previously. The
tools' -o and -i options work with either a file name or directory name.
Example:
$ sudo perf record --kcore uname
$ sudo tree perf.data
perf.data
├── kcore_dir
│ ├── kallsyms
│ ├── kcore
│ └── modules
└── data
$ sudo perf script -v
build id event received for vmlinux: 1eaa285996affce2d74d8e66dcea09a80c9941de
build id event received for [vdso]: 8bbaf5dc62a9b644b4d4e4539737e104e4a84541
Samples for 'cycles' event do not have CPU attribute set. Skipping 'cpu' field.
Using CPUID GenuineIntel-6-8E-A
Using perf.data/kcore_dir/kcore for kernel data
Using perf.data/kcore_dir/kallsyms for symbols
perf 19058 506778.423729: 1 cycles: ffffffffa2caa548 native_write_msr+0x8 (vmlinux)
perf 19058 506778.423733: 1 cycles: ffffffffa2caa548 native_write_msr+0x8 (vmlinux)
perf 19058 506778.423734: 7 cycles: ffffffffa2caa548 native_write_msr+0x8 (vmlinux)
perf 19058 506778.423736: 117 cycles: ffffffffa2caa54a native_write_msr+0xa (vmlinux)
perf 19058 506778.423738: 2092 cycles: ffffffffa2c9b7b0 native_apic_msr_write+0x0 (vmlinux)
perf 19058 506778.423740: 37380 cycles: ffffffffa2f121d0 perf_event_addr_filters_exec+0x0 (vmlinux)
uname 19058 506778.423751: 582673 cycles: ffffffffa303a407 propagate_protected_usage+0x147 (vmlinux)
uname 19058 506778.423892: 2241841 cycles: ffffffffa2cae0c9 unwind_next_frame.part.5+0x79 (vmlinux)
uname 19058 506778.424430: 2457397 cycles: ffffffffa3019232 check_memory_region+0x52 (vmlinux)
Committer testing:
# rm -rf perf.data*
# perf record sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.024 MB perf.data (7 samples) ]
# ls -l perf.data
-rw-------. 1 root root 34772 Oct 21 11:08 perf.data
# perf record --kcore uname
Linux
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.024 MB perf.data (7 samples) ]
ls[root@quaco ~]# ls -lad perf.data*
drwx------. 3 root root 4096 Oct 21 11:08 perf.data
-rw-------. 1 root root 34772 Oct 21 11:08 perf.data.old
# perf evlist -v
cycles: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|PERIOD, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1
# perf evlist -v -i perf.data/data
cycles: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|PERIOD, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1
#
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: http://lore.kernel.org/lkml/20191004083121.12182-6-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-10-04 08:31:21 +00:00
|
|
|
|
|
|
|
if (!symbol_conf.kallsyms_name &&
|
|
|
|
!symbol_conf.vmlinux_name)
|
|
|
|
symbol_conf.kallsyms_name = perf_data__kallsyms_name(data);
|
2013-10-15 14:27:33 +00:00
|
|
|
}
|
2015-09-09 15:25:00 +00:00
|
|
|
} else {
|
|
|
|
session->machines.host.env = &perf_env;
|
2013-10-15 14:27:33 +00:00
|
|
|
}
|
|
|
|
|
2018-11-06 21:07:10 +00:00
|
|
|
session->machines.host.single_address_space =
|
|
|
|
perf_env__single_address_space(session->machines.host.env);
|
|
|
|
|
2017-01-23 21:07:59 +00:00
|
|
|
if (!data || perf_data__is_write(data)) {
|
2010-01-27 23:05:52 +00:00
|
|
|
/*
|
|
|
|
* In O_RDONLY mode this will be performed when reading the
|
2011-01-29 16:01:45 +00:00
|
|
|
* kernel MMAP event, in perf_event__process_mmap().
|
2010-01-27 23:05:52 +00:00
|
|
|
*/
|
2013-11-05 18:32:36 +00:00
|
|
|
if (perf_session__create_kernel_maps(session) < 0)
|
2014-09-24 21:39:54 +00:00
|
|
|
pr_warning("Cannot read kernel map\n");
|
2010-01-27 23:05:52 +00:00
|
|
|
}
|
2009-12-27 23:37:02 +00:00
|
|
|
|
2017-04-10 20:14:30 +00:00
|
|
|
/*
|
|
|
|
* In pipe-mode, evlist is empty until PERF_RECORD_HEADER_ATTR is
|
2020-06-17 12:29:48 +00:00
|
|
|
* processed, so evlist__sample_id_all is not meaningful here.
|
2017-04-10 20:14:30 +00:00
|
|
|
*/
|
2017-01-23 21:07:59 +00:00
|
|
|
if ((!data || !data->is_pipe) && tool && tool->ordering_requires_timestamps &&
|
2020-06-17 12:29:48 +00:00
|
|
|
tool->ordered_events && !evlist__sample_id_all(session->evlist)) {
|
2010-12-10 03:09:16 +00:00
|
|
|
dump_printf("WARNING: No sample_id_all support, falling back to unordered processing\n");
|
2014-07-06 12:18:21 +00:00
|
|
|
tool->ordered_events = false;
|
2015-03-03 15:20:38 +00:00
|
|
|
}
|
2010-12-10 03:09:16 +00:00
|
|
|
|
2013-11-05 18:32:36 +00:00
|
|
|
return session;
|
2013-10-15 14:27:33 +00:00
|
|
|
|
|
|
|
out_delete:
|
2013-11-05 18:32:36 +00:00
|
|
|
perf_session__delete(session);
|
2013-10-15 14:27:33 +00:00
|
|
|
out:
|
2019-08-22 07:20:49 +00:00
|
|
|
return ERR_PTR(ret);
|
2009-12-11 23:24:02 +00:00
|
|
|
}
|
|
|
|
|
2011-11-09 15:24:25 +00:00
|
|
|
static void perf_session__delete_threads(struct perf_session *session)
|
|
|
|
{
|
2012-12-18 22:15:48 +00:00
|
|
|
machine__delete_threads(&session->machines.host);
|
2011-11-09 15:24:25 +00:00
|
|
|
}
|
|
|
|
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
static void perf_session__release_decomp_events(struct perf_session *session)
|
|
|
|
{
|
|
|
|
struct decomp *next, *decomp;
|
2019-07-09 14:48:14 +00:00
|
|
|
size_t mmap_len;
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
next = session->decomp;
|
|
|
|
do {
|
|
|
|
decomp = next;
|
|
|
|
if (decomp == NULL)
|
|
|
|
break;
|
|
|
|
next = decomp->next;
|
2019-07-09 14:48:14 +00:00
|
|
|
mmap_len = decomp->mmap_len;
|
|
|
|
munmap(decomp, mmap_len);
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
} while (1);
|
|
|
|
}
|
|
|
|
|
2013-11-05 18:32:36 +00:00
|
|
|
void perf_session__delete(struct perf_session *session)
|
2009-12-11 23:24:02 +00:00
|
|
|
{
|
2016-06-22 13:02:16 +00:00
|
|
|
if (session == NULL)
|
|
|
|
return;
|
2015-04-09 15:53:48 +00:00
|
|
|
auxtrace__free(session);
|
2015-04-30 14:37:25 +00:00
|
|
|
auxtrace_index__free(&session->auxtrace_index);
|
2013-11-05 18:32:36 +00:00
|
|
|
perf_session__destroy_kernel_maps(session);
|
|
|
|
perf_session__delete_threads(session);
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
perf_session__release_decomp_events(session);
|
2015-09-08 16:30:00 +00:00
|
|
|
perf_env__exit(&session->header.env);
|
2013-11-05 18:32:36 +00:00
|
|
|
machines__exit(&session->machines);
|
2017-01-23 21:07:59 +00:00
|
|
|
if (session->data)
|
|
|
|
perf_data__close(session->data);
|
2013-11-05 18:32:36 +00:00
|
|
|
free(session);
|
2009-12-11 23:24:02 +00:00
|
|
|
}
|
2009-12-14 16:22:59 +00:00
|
|
|
|
2018-09-13 12:54:03 +00:00
|
|
|
static int process_event_synth_tracing_data_stub(struct perf_session *session
|
2013-07-04 13:20:21 +00:00
|
|
|
__maybe_unused,
|
|
|
|
union perf_event *event
|
2018-09-13 12:54:03 +00:00
|
|
|
__maybe_unused)
|
2011-11-25 10:19:45 +00:00
|
|
|
{
|
|
|
|
dump_printf(": unhandled!\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-07-04 13:20:21 +00:00
|
|
|
static int process_event_synth_attr_stub(struct perf_tool *tool __maybe_unused,
|
|
|
|
union perf_event *event __maybe_unused,
|
2019-07-21 11:23:52 +00:00
|
|
|
struct evlist **pevlist
|
2012-09-10 22:15:03 +00:00
|
|
|
__maybe_unused)
|
2011-11-12 00:45:41 +00:00
|
|
|
{
|
|
|
|
dump_printf(": unhandled!\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-10-25 14:51:36 +00:00
|
|
|
static int process_event_synth_event_update_stub(struct perf_tool *tool __maybe_unused,
|
|
|
|
union perf_event *event __maybe_unused,
|
2019-07-21 11:23:52 +00:00
|
|
|
struct evlist **pevlist
|
2015-10-25 14:51:36 +00:00
|
|
|
__maybe_unused)
|
|
|
|
{
|
2015-10-25 14:51:42 +00:00
|
|
|
if (dump_trace)
|
|
|
|
perf_event__fprintf_event_update(event, stdout);
|
|
|
|
|
2015-10-25 14:51:36 +00:00
|
|
|
dump_printf(": unhandled!\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-09-10 22:15:03 +00:00
|
|
|
static int process_event_sample_stub(struct perf_tool *tool __maybe_unused,
|
|
|
|
union perf_event *event __maybe_unused,
|
|
|
|
struct perf_sample *sample __maybe_unused,
|
2019-07-21 11:23:51 +00:00
|
|
|
struct evsel *evsel __maybe_unused,
|
2012-09-10 22:15:03 +00:00
|
|
|
struct machine *machine __maybe_unused)
|
2011-03-15 18:44:01 +00:00
|
|
|
{
|
|
|
|
dump_printf(": unhandled!\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-09-10 22:15:03 +00:00
|
|
|
static int process_event_stub(struct perf_tool *tool __maybe_unused,
|
|
|
|
union perf_event *event __maybe_unused,
|
|
|
|
struct perf_sample *sample __maybe_unused,
|
|
|
|
struct machine *machine __maybe_unused)
|
2009-12-27 23:36:59 +00:00
|
|
|
{
|
|
|
|
dump_printf(": unhandled!\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-09-10 22:15:03 +00:00
|
|
|
static int process_finished_round_stub(struct perf_tool *tool __maybe_unused,
|
|
|
|
union perf_event *event __maybe_unused,
|
2015-03-03 15:37:54 +00:00
|
|
|
struct ordered_events *oe __maybe_unused)
|
2011-11-28 09:56:39 +00:00
|
|
|
{
|
|
|
|
dump_printf(": unhandled!\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-11-28 10:30:20 +00:00
|
|
|
static int process_finished_round(struct perf_tool *tool,
|
2011-11-25 10:19:45 +00:00
|
|
|
union perf_event *event,
|
2015-03-03 15:37:54 +00:00
|
|
|
struct ordered_events *oe);
|
2010-05-03 13:14:33 +00:00
|
|
|
|
2015-04-09 15:53:43 +00:00
|
|
|
static int skipn(int fd, off_t n)
|
|
|
|
{
|
|
|
|
char buf[4096];
|
|
|
|
ssize_t ret;
|
|
|
|
|
|
|
|
while (n > 0) {
|
|
|
|
ret = read(fd, buf, min(n, (off_t)sizeof(buf)));
|
|
|
|
if (ret <= 0)
|
|
|
|
return ret;
|
|
|
|
n -= ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-09-13 12:54:04 +00:00
|
|
|
static s64 process_event_auxtrace_stub(struct perf_session *session __maybe_unused,
|
|
|
|
union perf_event *event)
|
2015-04-09 15:53:43 +00:00
|
|
|
{
|
|
|
|
dump_printf(": unhandled!\n");
|
2017-01-23 21:07:59 +00:00
|
|
|
if (perf_data__is_pipe(session->data))
|
|
|
|
skipn(perf_data__fd(session->data), event->auxtrace.size);
|
2015-04-09 15:53:43 +00:00
|
|
|
return event->auxtrace.size;
|
|
|
|
}
|
|
|
|
|
2018-09-13 12:54:03 +00:00
|
|
|
static int process_event_op2_stub(struct perf_session *session __maybe_unused,
|
|
|
|
union perf_event *event __maybe_unused)
|
2015-04-09 15:53:47 +00:00
|
|
|
{
|
|
|
|
dump_printf(": unhandled!\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-10-25 14:51:19 +00:00
|
|
|
|
|
|
|
static
|
2018-09-13 12:54:03 +00:00
|
|
|
int process_event_thread_map_stub(struct perf_session *session __maybe_unused,
|
|
|
|
union perf_event *event __maybe_unused)
|
2015-10-25 14:51:19 +00:00
|
|
|
{
|
2015-10-25 14:51:42 +00:00
|
|
|
if (dump_trace)
|
|
|
|
perf_event__fprintf_thread_map(event, stdout);
|
|
|
|
|
2015-10-25 14:51:19 +00:00
|
|
|
dump_printf(": unhandled!\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-10-25 14:51:23 +00:00
|
|
|
static
|
2018-09-13 12:54:03 +00:00
|
|
|
int process_event_cpu_map_stub(struct perf_session *session __maybe_unused,
|
|
|
|
union perf_event *event __maybe_unused)
|
2015-10-25 14:51:23 +00:00
|
|
|
{
|
2015-10-25 14:51:42 +00:00
|
|
|
if (dump_trace)
|
|
|
|
perf_event__fprintf_cpu_map(event, stdout);
|
|
|
|
|
2015-10-25 14:51:23 +00:00
|
|
|
dump_printf(": unhandled!\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-10-25 14:51:27 +00:00
|
|
|
static
|
2018-09-13 12:54:03 +00:00
|
|
|
int process_event_stat_config_stub(struct perf_session *session __maybe_unused,
|
|
|
|
union perf_event *event __maybe_unused)
|
2015-10-25 14:51:27 +00:00
|
|
|
{
|
2015-10-25 14:51:42 +00:00
|
|
|
if (dump_trace)
|
|
|
|
perf_event__fprintf_stat_config(event, stdout);
|
|
|
|
|
2015-10-25 14:51:27 +00:00
|
|
|
dump_printf(": unhandled!\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-09-13 12:54:03 +00:00
|
|
|
static int process_stat_stub(struct perf_session *perf_session __maybe_unused,
|
|
|
|
union perf_event *event)
|
2015-10-25 14:51:30 +00:00
|
|
|
{
|
2015-10-25 14:51:42 +00:00
|
|
|
if (dump_trace)
|
|
|
|
perf_event__fprintf_stat(event, stdout);
|
|
|
|
|
2015-10-25 14:51:30 +00:00
|
|
|
dump_printf(": unhandled!\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-09-13 12:54:03 +00:00
|
|
|
static int process_stat_round_stub(struct perf_session *perf_session __maybe_unused,
|
|
|
|
union perf_event *event)
|
2015-10-25 14:51:33 +00:00
|
|
|
{
|
2015-10-25 14:51:42 +00:00
|
|
|
if (dump_trace)
|
|
|
|
perf_event__fprintf_stat_round(event, stdout);
|
|
|
|
|
2015-10-25 14:51:33 +00:00
|
|
|
dump_printf(": unhandled!\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-18 17:45:11 +00:00
|
|
|
static int perf_session__process_compressed_event_stub(struct perf_session *session __maybe_unused,
|
|
|
|
union perf_event *event __maybe_unused,
|
|
|
|
u64 file_offset __maybe_unused)
|
|
|
|
{
|
|
|
|
dump_printf(": unhandled!\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-08-02 20:05:41 +00:00
|
|
|
void perf_tool__fill_defaults(struct perf_tool *tool)
|
2009-12-27 23:36:59 +00:00
|
|
|
{
|
2011-11-28 10:30:20 +00:00
|
|
|
if (tool->sample == NULL)
|
|
|
|
tool->sample = process_event_sample_stub;
|
|
|
|
if (tool->mmap == NULL)
|
|
|
|
tool->mmap = process_event_stub;
|
2013-09-23 01:44:59 +00:00
|
|
|
if (tool->mmap2 == NULL)
|
|
|
|
tool->mmap2 = process_event_stub;
|
2011-11-28 10:30:20 +00:00
|
|
|
if (tool->comm == NULL)
|
|
|
|
tool->comm = process_event_stub;
|
perf buildid-list: Fix crash when processing PERF_RECORD_NAMESPACE
Thomas reported that 'perf buildid-list' gets a SEGFAULT due to NULL
pointer deref when he ran it on a data with namespace events. It was
because the buildid_id__mark_dso_hit_ops lacks the namespace event
handler and perf_too__fill_default() didn't set it.
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
Missing separate debuginfos, use: dnf debuginfo-install audit-libs-2.7.7-1.fc25.s390x bzip2-libs-1.0.6-21.fc25.s390x elfutils-libelf-0.169-1.fc25.s390x
+elfutils-libs-0.169-1.fc25.s390x libcap-ng-0.7.8-1.fc25.s390x numactl-libs-2.0.11-2.ibm.fc25.s390x openssl-libs-1.1.0e-1.1.ibm.fc25.s390x perl-libs-5.24.1-386.fc25.s390x
+python-libs-2.7.13-2.fc25.s390x slang-2.3.0-7.fc25.s390x xz-libs-5.2.3-2.fc25.s390x zlib-1.2.8-10.fc25.s390x
(gdb) where
#0 0x0000000000000000 in ?? ()
#1 0x00000000010fad6a in machines__deliver_event (machines=<optimized out>, machines@entry=0x2c6fd18,
evlist=<optimized out>, event=event@entry=0x3fffdf00470, sample=0x3ffffffe880, sample@entry=0x3ffffffe888,
tool=tool@entry=0x1312968 <build_id.mark_dso_hit_ops>, file_offset=1136) at util/session.c:1287
#2 0x00000000010fbf4e in perf_session__deliver_event (file_offset=1136, tool=0x1312968 <build_id.mark_dso_hit_ops>,
sample=0x3ffffffe888, event=0x3fffdf00470, session=0x2c6fc30) at util/session.c:1340
#3 perf_session__process_event (session=0x2c6fc30, session@entry=0x0, event=event@entry=0x3fffdf00470,
file_offset=file_offset@entry=1136) at util/session.c:1522
#4 0x00000000010fddde in __perf_session__process_events (file_size=11880, data_size=<optimized out>,
data_offset=<optimized out>, session=0x0) at util/session.c:1899
#5 perf_session__process_events (session=0x0, session@entry=0x2c6fc30) at util/session.c:1953
#6 0x000000000103b2ac in perf_session__list_build_ids (with_hits=<optimized out>, force=<optimized out>)
at builtin-buildid-list.c:83
#7 cmd_buildid_list (argc=<optimized out>, argv=<optimized out>) at builtin-buildid-list.c:115
#8 0x00000000010a026c in run_builtin (p=0x1311f78 <commands+24>, argc=argc@entry=2, argv=argv@entry=0x3fffffff3c0)
at perf.c:296
#9 0x000000000102bc00 in handle_internal_command (argv=<optimized out>, argc=2) at perf.c:348
#10 run_argv (argcp=<synthetic pointer>, argv=<synthetic pointer>) at perf.c:392
#11 main (argc=<optimized out>, argv=0x3fffffff3c0) at perf.c:536
(gdb)
Fix it by adding a stub event handler for namespace event.
Committer testing:
Further clarifying, plain using 'perf buildid-list' will not end up in a
SEGFAULT when processing a perf.data file with namespace info:
# perf record -a --namespaces sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 2.024 MB perf.data (1058 samples) ]
# perf buildid-list | wc -l
38
# perf buildid-list | head -5
e2a171c7b905826fc8494f0711ba76ab6abbd604 /lib/modules/4.14.0-rc3+/build/vmlinux
874840a02d8f8a31cedd605d0b8653145472ced3 /lib/modules/4.14.0-rc3+/kernel/arch/x86/kvm/kvm-intel.ko
ea7223776730cd8a22f320040aae4d54312984bc /lib/modules/4.14.0-rc3+/kernel/drivers/gpu/drm/i915/i915.ko
5961535e6732a8edb7f22b3f148bb2fa2e0be4b9 /lib/modules/4.14.0-rc3+/kernel/drivers/gpu/drm/drm.ko
f045f54aa78cf1931cc893f78b6cbc52c72a8cb1 /usr/lib64/libc-2.25.so
#
It is only when one asks for checking what of those entries actually had
samples, i.e. when we use either -H or --with-hits, that we will process
all the PERF_RECORD_ events, and since tools/perf/builtin-buildid-list.c
neither explicitely set a perf_tool.namespaces() callback nor the
default stub was set that we end up, when processing a
PERF_RECORD_NAMESPACE record, causing a SEGFAULT:
# perf buildid-list -H
Segmentation fault (core dumped)
^C
#
Reported-and-Tested-by: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
Fixes: f3b3614a284d ("perf tools: Add PERF_RECORD_NAMESPACES to include namespaces related info")
Link: http://lkml.kernel.org/r/20171017132900.11043-1-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-10-17 13:29:00 +00:00
|
|
|
if (tool->namespaces == NULL)
|
|
|
|
tool->namespaces = process_event_stub;
|
2020-03-25 12:45:30 +00:00
|
|
|
if (tool->cgroup == NULL)
|
|
|
|
tool->cgroup = process_event_stub;
|
2011-11-28 10:30:20 +00:00
|
|
|
if (tool->fork == NULL)
|
|
|
|
tool->fork = process_event_stub;
|
|
|
|
if (tool->exit == NULL)
|
|
|
|
tool->exit = process_event_stub;
|
|
|
|
if (tool->lost == NULL)
|
|
|
|
tool->lost = perf_event__process_lost;
|
2015-05-10 19:13:15 +00:00
|
|
|
if (tool->lost_samples == NULL)
|
|
|
|
tool->lost_samples = perf_event__process_lost_samples;
|
2015-04-30 14:37:29 +00:00
|
|
|
if (tool->aux == NULL)
|
|
|
|
tool->aux = perf_event__process_aux;
|
2015-04-30 14:37:30 +00:00
|
|
|
if (tool->itrace_start == NULL)
|
|
|
|
tool->itrace_start = perf_event__process_itrace_start;
|
2015-07-21 09:44:03 +00:00
|
|
|
if (tool->context_switch == NULL)
|
|
|
|
tool->context_switch = perf_event__process_switch;
|
2019-01-17 16:15:17 +00:00
|
|
|
if (tool->ksymbol == NULL)
|
|
|
|
tool->ksymbol = perf_event__process_ksymbol;
|
2019-08-26 22:28:13 +00:00
|
|
|
if (tool->bpf == NULL)
|
|
|
|
tool->bpf = perf_event__process_bpf;
|
2020-05-12 12:19:18 +00:00
|
|
|
if (tool->text_poke == NULL)
|
|
|
|
tool->text_poke = perf_event__process_text_poke;
|
2011-11-28 10:30:20 +00:00
|
|
|
if (tool->read == NULL)
|
|
|
|
tool->read = process_event_sample_stub;
|
|
|
|
if (tool->throttle == NULL)
|
|
|
|
tool->throttle = process_event_stub;
|
|
|
|
if (tool->unthrottle == NULL)
|
|
|
|
tool->unthrottle = process_event_stub;
|
|
|
|
if (tool->attr == NULL)
|
|
|
|
tool->attr = process_event_synth_attr_stub;
|
2015-10-25 14:51:36 +00:00
|
|
|
if (tool->event_update == NULL)
|
|
|
|
tool->event_update = process_event_synth_event_update_stub;
|
2011-11-28 10:30:20 +00:00
|
|
|
if (tool->tracing_data == NULL)
|
|
|
|
tool->tracing_data = process_event_synth_tracing_data_stub;
|
|
|
|
if (tool->build_id == NULL)
|
2016-03-07 19:44:39 +00:00
|
|
|
tool->build_id = process_event_op2_stub;
|
2011-11-28 10:30:20 +00:00
|
|
|
if (tool->finished_round == NULL) {
|
2014-07-06 12:18:21 +00:00
|
|
|
if (tool->ordered_events)
|
2011-11-28 10:30:20 +00:00
|
|
|
tool->finished_round = process_finished_round;
|
2010-05-03 13:14:33 +00:00
|
|
|
else
|
2011-11-28 10:30:20 +00:00
|
|
|
tool->finished_round = process_finished_round_stub;
|
2010-05-03 13:14:33 +00:00
|
|
|
}
|
2014-10-27 13:49:22 +00:00
|
|
|
if (tool->id_index == NULL)
|
2016-03-07 19:44:39 +00:00
|
|
|
tool->id_index = process_event_op2_stub;
|
2015-04-09 15:53:43 +00:00
|
|
|
if (tool->auxtrace_info == NULL)
|
2016-03-07 19:44:39 +00:00
|
|
|
tool->auxtrace_info = process_event_op2_stub;
|
2015-04-09 15:53:43 +00:00
|
|
|
if (tool->auxtrace == NULL)
|
|
|
|
tool->auxtrace = process_event_auxtrace_stub;
|
2015-04-09 15:53:47 +00:00
|
|
|
if (tool->auxtrace_error == NULL)
|
2016-03-07 19:44:39 +00:00
|
|
|
tool->auxtrace_error = process_event_op2_stub;
|
2015-10-25 14:51:19 +00:00
|
|
|
if (tool->thread_map == NULL)
|
|
|
|
tool->thread_map = process_event_thread_map_stub;
|
2015-10-25 14:51:23 +00:00
|
|
|
if (tool->cpu_map == NULL)
|
|
|
|
tool->cpu_map = process_event_cpu_map_stub;
|
2015-10-25 14:51:27 +00:00
|
|
|
if (tool->stat_config == NULL)
|
|
|
|
tool->stat_config = process_event_stat_config_stub;
|
2015-10-25 14:51:30 +00:00
|
|
|
if (tool->stat == NULL)
|
|
|
|
tool->stat = process_stat_stub;
|
2015-10-25 14:51:33 +00:00
|
|
|
if (tool->stat_round == NULL)
|
|
|
|
tool->stat_round = process_stat_round_stub;
|
2016-03-08 08:38:44 +00:00
|
|
|
if (tool->time_conv == NULL)
|
|
|
|
tool->time_conv = process_event_op2_stub;
|
perf tools: Add feature header record to pipe-mode
Add header record types to pipe-mode, reusing the functions
used in file-mode and leveraging the new struct feat_fd.
For alignment, check that synthesized events don't exceed
pagesize.
Add the perf_event__synthesize_feature event call back to
process the new header records.
Before this patch:
$ perf record -o - -e cycles sleep 1 | perf report --stdio --header
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.000 MB - ]
...
After this patch:
$ perf record -o - -e cycles sleep 1 | perf report --stdio --header
# ========
# captured on: Mon May 22 16:33:43 2017
# ========
#
# hostname : my_hostname
# os release : 4.11.0-dbx-up_perf
# perf version : 4.11.rc6.g6277c80
# arch : x86_64
# nrcpus online : 72
# nrcpus avail : 72
# cpudesc : Intel(R) Xeon(R) CPU E5-2696 v3 @ 2.30GHz
# cpuid : GenuineIntel,6,63,2
# total memory : 263457192 kB
# cmdline : /root/perf record -o - -e cycles -c 100000 sleep 1
# HEADER_CPU_TOPOLOGY info available, use -I to display
# HEADER_NUMA_TOPOLOGY info available, use -I to display
# pmu mappings: intel_bts = 6, uncore_imc_4 = 22, uncore_sbox_1 = 47, uncore_cbox_5 = 33, uncore_ha_0 = 16, uncore_cbox
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.000 MB - ]
...
Support added for the subcommands: report, inject, annotate and script.
Signed-off-by: David Carrillo-Cisneros <davidcc@google.com>
Acked-by: David Ahern <dsahern@gmail.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Turner <pjt@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Simon Que <sque@chromium.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/20170718042549.145161-16-davidcc@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-07-18 04:25:48 +00:00
|
|
|
if (tool->feature == NULL)
|
|
|
|
tool->feature = process_event_op2_stub;
|
2019-03-18 17:45:11 +00:00
|
|
|
if (tool->compressed == NULL)
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
tool->compressed = perf_session__process_compressed_event;
|
2009-12-27 23:36:59 +00:00
|
|
|
}
|
2014-12-17 20:24:45 +00:00
|
|
|
|
2012-05-30 12:23:43 +00:00
|
|
|
static void swap_sample_id_all(union perf_event *event, void *data)
|
|
|
|
{
|
|
|
|
void *end = (void *) event + event->header.size;
|
|
|
|
int size = end - data;
|
|
|
|
|
|
|
|
BUG_ON(size % sizeof(u64));
|
|
|
|
mem_bswap_64(data, size);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void perf_event__all64_swap(union perf_event *event,
|
2012-09-10 22:15:03 +00:00
|
|
|
bool sample_id_all __maybe_unused)
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
{
|
2011-01-29 16:01:45 +00:00
|
|
|
struct perf_event_header *hdr = &event->header;
|
|
|
|
mem_bswap_64(hdr + 1, event->header.size - sizeof(*hdr));
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
}
|
|
|
|
|
2012-05-30 12:23:43 +00:00
|
|
|
static void perf_event__comm_swap(union perf_event *event, bool sample_id_all)
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
{
|
2011-01-29 16:01:45 +00:00
|
|
|
event->comm.pid = bswap_32(event->comm.pid);
|
|
|
|
event->comm.tid = bswap_32(event->comm.tid);
|
2012-05-30 12:23:43 +00:00
|
|
|
|
|
|
|
if (sample_id_all) {
|
|
|
|
void *data = &event->comm.comm;
|
|
|
|
|
2012-09-10 22:15:01 +00:00
|
|
|
data += PERF_ALIGN(strlen(data) + 1, sizeof(u64));
|
2012-05-30 12:23:43 +00:00
|
|
|
swap_sample_id_all(event, data);
|
|
|
|
}
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
}
|
|
|
|
|
2012-05-30 12:23:43 +00:00
|
|
|
static void perf_event__mmap_swap(union perf_event *event,
|
|
|
|
bool sample_id_all)
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
{
|
2011-01-29 16:01:45 +00:00
|
|
|
event->mmap.pid = bswap_32(event->mmap.pid);
|
|
|
|
event->mmap.tid = bswap_32(event->mmap.tid);
|
|
|
|
event->mmap.start = bswap_64(event->mmap.start);
|
|
|
|
event->mmap.len = bswap_64(event->mmap.len);
|
|
|
|
event->mmap.pgoff = bswap_64(event->mmap.pgoff);
|
2012-05-30 12:23:43 +00:00
|
|
|
|
|
|
|
if (sample_id_all) {
|
|
|
|
void *data = &event->mmap.filename;
|
|
|
|
|
2012-09-10 22:15:01 +00:00
|
|
|
data += PERF_ALIGN(strlen(data) + 1, sizeof(u64));
|
2012-05-30 12:23:43 +00:00
|
|
|
swap_sample_id_all(event, data);
|
|
|
|
}
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
}
|
|
|
|
|
2013-08-21 10:10:25 +00:00
|
|
|
static void perf_event__mmap2_swap(union perf_event *event,
|
|
|
|
bool sample_id_all)
|
|
|
|
{
|
|
|
|
event->mmap2.pid = bswap_32(event->mmap2.pid);
|
|
|
|
event->mmap2.tid = bswap_32(event->mmap2.tid);
|
|
|
|
event->mmap2.start = bswap_64(event->mmap2.start);
|
|
|
|
event->mmap2.len = bswap_64(event->mmap2.len);
|
|
|
|
event->mmap2.pgoff = bswap_64(event->mmap2.pgoff);
|
2020-12-14 10:54:47 +00:00
|
|
|
|
|
|
|
if (!(event->header.misc & PERF_RECORD_MISC_MMAP_BUILD_ID)) {
|
|
|
|
event->mmap2.maj = bswap_32(event->mmap2.maj);
|
|
|
|
event->mmap2.min = bswap_32(event->mmap2.min);
|
|
|
|
event->mmap2.ino = bswap_64(event->mmap2.ino);
|
|
|
|
event->mmap2.ino_generation = bswap_64(event->mmap2.ino_generation);
|
|
|
|
}
|
2013-08-21 10:10:25 +00:00
|
|
|
|
|
|
|
if (sample_id_all) {
|
|
|
|
void *data = &event->mmap2.filename;
|
|
|
|
|
|
|
|
data += PERF_ALIGN(strlen(data) + 1, sizeof(u64));
|
|
|
|
swap_sample_id_all(event, data);
|
|
|
|
}
|
|
|
|
}
|
2012-05-30 12:23:43 +00:00
|
|
|
static void perf_event__task_swap(union perf_event *event, bool sample_id_all)
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
{
|
2011-01-29 16:01:45 +00:00
|
|
|
event->fork.pid = bswap_32(event->fork.pid);
|
|
|
|
event->fork.tid = bswap_32(event->fork.tid);
|
|
|
|
event->fork.ppid = bswap_32(event->fork.ppid);
|
|
|
|
event->fork.ptid = bswap_32(event->fork.ptid);
|
|
|
|
event->fork.time = bswap_64(event->fork.time);
|
2012-05-30 12:23:43 +00:00
|
|
|
|
|
|
|
if (sample_id_all)
|
|
|
|
swap_sample_id_all(event, &event->fork + 1);
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
}
|
|
|
|
|
2012-05-30 12:23:43 +00:00
|
|
|
static void perf_event__read_swap(union perf_event *event, bool sample_id_all)
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
{
|
2011-01-29 16:01:45 +00:00
|
|
|
event->read.pid = bswap_32(event->read.pid);
|
|
|
|
event->read.tid = bswap_32(event->read.tid);
|
|
|
|
event->read.value = bswap_64(event->read.value);
|
|
|
|
event->read.time_enabled = bswap_64(event->read.time_enabled);
|
|
|
|
event->read.time_running = bswap_64(event->read.time_running);
|
|
|
|
event->read.id = bswap_64(event->read.id);
|
2012-05-30 12:23:43 +00:00
|
|
|
|
|
|
|
if (sample_id_all)
|
|
|
|
swap_sample_id_all(event, &event->read + 1);
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
}
|
|
|
|
|
2015-04-30 14:37:29 +00:00
|
|
|
static void perf_event__aux_swap(union perf_event *event, bool sample_id_all)
|
|
|
|
{
|
|
|
|
event->aux.aux_offset = bswap_64(event->aux.aux_offset);
|
|
|
|
event->aux.aux_size = bswap_64(event->aux.aux_size);
|
|
|
|
event->aux.flags = bswap_64(event->aux.flags);
|
|
|
|
|
|
|
|
if (sample_id_all)
|
|
|
|
swap_sample_id_all(event, &event->aux + 1);
|
|
|
|
}
|
|
|
|
|
2015-04-30 14:37:30 +00:00
|
|
|
static void perf_event__itrace_start_swap(union perf_event *event,
|
|
|
|
bool sample_id_all)
|
|
|
|
{
|
|
|
|
event->itrace_start.pid = bswap_32(event->itrace_start.pid);
|
|
|
|
event->itrace_start.tid = bswap_32(event->itrace_start.tid);
|
|
|
|
|
|
|
|
if (sample_id_all)
|
|
|
|
swap_sample_id_all(event, &event->itrace_start + 1);
|
|
|
|
}
|
|
|
|
|
2015-07-21 09:44:03 +00:00
|
|
|
static void perf_event__switch_swap(union perf_event *event, bool sample_id_all)
|
|
|
|
{
|
|
|
|
if (event->header.type == PERF_RECORD_SWITCH_CPU_WIDE) {
|
|
|
|
event->context_switch.next_prev_pid =
|
|
|
|
bswap_32(event->context_switch.next_prev_pid);
|
|
|
|
event->context_switch.next_prev_tid =
|
|
|
|
bswap_32(event->context_switch.next_prev_tid);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (sample_id_all)
|
|
|
|
swap_sample_id_all(event, &event->context_switch + 1);
|
|
|
|
}
|
|
|
|
|
2020-05-12 12:19:18 +00:00
|
|
|
static void perf_event__text_poke_swap(union perf_event *event, bool sample_id_all)
|
|
|
|
{
|
|
|
|
event->text_poke.addr = bswap_64(event->text_poke.addr);
|
|
|
|
event->text_poke.old_len = bswap_16(event->text_poke.old_len);
|
|
|
|
event->text_poke.new_len = bswap_16(event->text_poke.new_len);
|
|
|
|
|
|
|
|
if (sample_id_all) {
|
|
|
|
size_t len = sizeof(event->text_poke.old_len) +
|
|
|
|
sizeof(event->text_poke.new_len) +
|
|
|
|
event->text_poke.old_len +
|
|
|
|
event->text_poke.new_len;
|
|
|
|
void *data = &event->text_poke.old_len;
|
|
|
|
|
|
|
|
data += PERF_ALIGN(len, sizeof(u64));
|
|
|
|
swap_sample_id_all(event, data);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-01 10:36:15 +00:00
|
|
|
static void perf_event__throttle_swap(union perf_event *event,
|
|
|
|
bool sample_id_all)
|
|
|
|
{
|
|
|
|
event->throttle.time = bswap_64(event->throttle.time);
|
|
|
|
event->throttle.id = bswap_64(event->throttle.id);
|
|
|
|
event->throttle.stream_id = bswap_64(event->throttle.stream_id);
|
|
|
|
|
|
|
|
if (sample_id_all)
|
|
|
|
swap_sample_id_all(event, &event->throttle + 1);
|
|
|
|
}
|
|
|
|
|
2019-05-22 05:32:49 +00:00
|
|
|
static void perf_event__namespaces_swap(union perf_event *event,
|
|
|
|
bool sample_id_all)
|
|
|
|
{
|
|
|
|
u64 i;
|
|
|
|
|
|
|
|
event->namespaces.pid = bswap_32(event->namespaces.pid);
|
|
|
|
event->namespaces.tid = bswap_32(event->namespaces.tid);
|
|
|
|
event->namespaces.nr_namespaces = bswap_64(event->namespaces.nr_namespaces);
|
|
|
|
|
|
|
|
for (i = 0; i < event->namespaces.nr_namespaces; i++) {
|
|
|
|
struct perf_ns_link_info *ns = &event->namespaces.link_info[i];
|
|
|
|
|
|
|
|
ns->dev = bswap_64(ns->dev);
|
|
|
|
ns->ino = bswap_64(ns->ino);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (sample_id_all)
|
|
|
|
swap_sample_id_all(event, &event->namespaces.link_info[i]);
|
|
|
|
}
|
|
|
|
|
2020-11-02 14:02:28 +00:00
|
|
|
static void perf_event__cgroup_swap(union perf_event *event, bool sample_id_all)
|
|
|
|
{
|
|
|
|
event->cgroup.id = bswap_64(event->cgroup.id);
|
|
|
|
|
|
|
|
if (sample_id_all) {
|
|
|
|
void *data = &event->cgroup.path;
|
|
|
|
|
|
|
|
data += PERF_ALIGN(strlen(data) + 1, sizeof(u64));
|
|
|
|
swap_sample_id_all(event, data);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-05-16 06:59:03 +00:00
|
|
|
static u8 revbyte(u8 b)
|
|
|
|
{
|
|
|
|
int rev = (b >> 4) | ((b & 0xf) << 4);
|
|
|
|
rev = ((rev & 0xcc) >> 2) | ((rev & 0x33) << 2);
|
|
|
|
rev = ((rev & 0xaa) >> 1) | ((rev & 0x55) << 1);
|
|
|
|
return (u8) rev;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* XXX this is hack in attempt to carry flags bitfield
|
2016-02-24 18:02:25 +00:00
|
|
|
* through endian village. ABI says:
|
2012-05-16 06:59:03 +00:00
|
|
|
*
|
|
|
|
* Bit-fields are allocated from right to left (least to most significant)
|
|
|
|
* on little-endian implementations and from left to right (most to least
|
|
|
|
* significant) on big-endian implementations.
|
|
|
|
*
|
|
|
|
* The above seems to be byte specific, so we need to reverse each
|
|
|
|
* byte of the bitfield. 'Internet' also says this might be implementation
|
|
|
|
* specific and we probably need proper fix and carry perf_event_attr
|
|
|
|
* bitfield flags in separate data file FEAT_ section. Thought this seems
|
|
|
|
* to work for now.
|
|
|
|
*/
|
|
|
|
static void swap_bitfield(u8 *p, unsigned len)
|
|
|
|
{
|
|
|
|
unsigned i;
|
|
|
|
|
|
|
|
for (i = 0; i < len; i++) {
|
|
|
|
*p = revbyte(*p);
|
|
|
|
p++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-07-15 18:34:09 +00:00
|
|
|
/* exported for swapping attributes in file header */
|
|
|
|
void perf_event__attr_swap(struct perf_event_attr *attr)
|
|
|
|
{
|
|
|
|
attr->type = bswap_32(attr->type);
|
|
|
|
attr->size = bswap_32(attr->size);
|
2015-06-17 09:56:39 +00:00
|
|
|
|
|
|
|
#define bswap_safe(f, n) \
|
|
|
|
(attr->size > (offsetof(struct perf_event_attr, f) + \
|
|
|
|
sizeof(attr->f) * (n)))
|
|
|
|
#define bswap_field(f, sz) \
|
|
|
|
do { \
|
|
|
|
if (bswap_safe(f, 0)) \
|
|
|
|
attr->f = bswap_##sz(attr->f); \
|
|
|
|
} while(0)
|
perf tools: Per event max-stack settings
The tooling counterpart, now it is possible to do:
# perf record -e sched:sched_switch/max-stack=10/ -e cycles/call-graph=dwarf,max-stack=4/ -e cpu-cycles/call-graph=dwarf,max-stack=1024/ usleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (5 samples) ]
# perf evlist -v
sched:sched_switch: type: 2, size: 112, config: 0x110, { sample_period, sample_freq }: 1, sample_type: IP|TID|TIME|CALLCHAIN|CPU|PERIOD|RAW|IDENTIFIER, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, enable_on_exec: 1, task: 1, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, sample_max_stack: 10
cycles/call-graph=dwarf,max-stack=4/: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CALLCHAIN|PERIOD|REGS_USER|STACK_USER|IDENTIFIER, read_format: ID, disabled: 1, inherit: 1, freq: 1, enable_on_exec: 1, sample_id_all: 1, exclude_guest: 1, exclude_callchain_user: 1, sample_regs_user: 0xff0fff, sample_stack_user: 8192, sample_max_stack: 4
cpu-cycles/call-graph=dwarf,max-stack=1024/: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CALLCHAIN|PERIOD|REGS_USER|STACK_USER|IDENTIFIER, read_format: ID, disabled: 1, inherit: 1, freq: 1, enable_on_exec: 1, sample_id_all: 1, exclude_guest: 1, exclude_callchain_user: 1, sample_regs_user: 0xff0fff, sample_stack_user: 8192, sample_max_stack: 1024
# Tip: use 'perf evlist --trace-fields' to show fields for tracepoint events
Using just /max-stack=N/ means /call-graph=fp,max-stack=N/, that should
be further configurable by means of some .perfconfig knob.
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: Linus Torvalds <torvalds@linux-foundation.org>
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-kolmn1yo40p7jhswxwrc7rrd@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-04-28 22:03:42 +00:00
|
|
|
#define bswap_field_16(f) bswap_field(f, 16)
|
2015-06-17 09:56:39 +00:00
|
|
|
#define bswap_field_32(f) bswap_field(f, 32)
|
|
|
|
#define bswap_field_64(f) bswap_field(f, 64)
|
|
|
|
|
|
|
|
bswap_field_64(config);
|
|
|
|
bswap_field_64(sample_period);
|
|
|
|
bswap_field_64(sample_type);
|
|
|
|
bswap_field_64(read_format);
|
|
|
|
bswap_field_32(wakeup_events);
|
|
|
|
bswap_field_32(bp_type);
|
|
|
|
bswap_field_64(bp_addr);
|
|
|
|
bswap_field_64(bp_len);
|
|
|
|
bswap_field_64(branch_sample_type);
|
|
|
|
bswap_field_64(sample_regs_user);
|
|
|
|
bswap_field_32(sample_stack_user);
|
|
|
|
bswap_field_32(aux_watermark);
|
perf tools: Per event max-stack settings
The tooling counterpart, now it is possible to do:
# perf record -e sched:sched_switch/max-stack=10/ -e cycles/call-graph=dwarf,max-stack=4/ -e cpu-cycles/call-graph=dwarf,max-stack=1024/ usleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (5 samples) ]
# perf evlist -v
sched:sched_switch: type: 2, size: 112, config: 0x110, { sample_period, sample_freq }: 1, sample_type: IP|TID|TIME|CALLCHAIN|CPU|PERIOD|RAW|IDENTIFIER, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, enable_on_exec: 1, task: 1, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, sample_max_stack: 10
cycles/call-graph=dwarf,max-stack=4/: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CALLCHAIN|PERIOD|REGS_USER|STACK_USER|IDENTIFIER, read_format: ID, disabled: 1, inherit: 1, freq: 1, enable_on_exec: 1, sample_id_all: 1, exclude_guest: 1, exclude_callchain_user: 1, sample_regs_user: 0xff0fff, sample_stack_user: 8192, sample_max_stack: 4
cpu-cycles/call-graph=dwarf,max-stack=1024/: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CALLCHAIN|PERIOD|REGS_USER|STACK_USER|IDENTIFIER, read_format: ID, disabled: 1, inherit: 1, freq: 1, enable_on_exec: 1, sample_id_all: 1, exclude_guest: 1, exclude_callchain_user: 1, sample_regs_user: 0xff0fff, sample_stack_user: 8192, sample_max_stack: 1024
# Tip: use 'perf evlist --trace-fields' to show fields for tracepoint events
Using just /max-stack=N/ means /call-graph=fp,max-stack=N/, that should
be further configurable by means of some .perfconfig knob.
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: Linus Torvalds <torvalds@linux-foundation.org>
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-kolmn1yo40p7jhswxwrc7rrd@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-04-28 22:03:42 +00:00
|
|
|
bswap_field_16(sample_max_stack);
|
2019-11-15 12:42:11 +00:00
|
|
|
bswap_field_32(aux_sample_size);
|
2015-06-17 09:56:39 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* After read_format are bitfields. Check read_format because
|
|
|
|
* we are unable to use offsetof on bitfield.
|
|
|
|
*/
|
|
|
|
if (bswap_safe(read_format, 1))
|
|
|
|
swap_bitfield((u8 *) (&attr->read_format + 1),
|
|
|
|
sizeof(u64));
|
|
|
|
#undef bswap_field_64
|
|
|
|
#undef bswap_field_32
|
|
|
|
#undef bswap_field
|
|
|
|
#undef bswap_safe
|
2011-07-15 18:34:09 +00:00
|
|
|
}
|
|
|
|
|
2012-05-30 12:23:43 +00:00
|
|
|
static void perf_event__hdr_attr_swap(union perf_event *event,
|
2012-09-10 22:15:03 +00:00
|
|
|
bool sample_id_all __maybe_unused)
|
2010-04-02 04:59:19 +00:00
|
|
|
{
|
|
|
|
size_t size;
|
|
|
|
|
2011-07-15 18:34:09 +00:00
|
|
|
perf_event__attr_swap(&event->attr.attr);
|
2010-04-02 04:59:19 +00:00
|
|
|
|
2011-01-29 16:01:45 +00:00
|
|
|
size = event->header.size;
|
|
|
|
size -= (void *)&event->attr.id - (void *)event;
|
|
|
|
mem_bswap_64(event->attr.id, size);
|
2010-04-02 04:59:19 +00:00
|
|
|
}
|
|
|
|
|
2015-10-25 14:51:36 +00:00
|
|
|
static void perf_event__event_update_swap(union perf_event *event,
|
|
|
|
bool sample_id_all __maybe_unused)
|
|
|
|
{
|
|
|
|
event->event_update.type = bswap_64(event->event_update.type);
|
|
|
|
event->event_update.id = bswap_64(event->event_update.id);
|
|
|
|
}
|
|
|
|
|
2012-05-30 12:23:43 +00:00
|
|
|
static void perf_event__event_type_swap(union perf_event *event,
|
2012-09-10 22:15:03 +00:00
|
|
|
bool sample_id_all __maybe_unused)
|
2010-04-02 04:59:20 +00:00
|
|
|
{
|
2011-01-29 16:01:45 +00:00
|
|
|
event->event_type.event_type.event_id =
|
|
|
|
bswap_64(event->event_type.event_type.event_id);
|
2010-04-02 04:59:20 +00:00
|
|
|
}
|
|
|
|
|
2012-05-30 12:23:43 +00:00
|
|
|
static void perf_event__tracing_data_swap(union perf_event *event,
|
2012-09-10 22:15:03 +00:00
|
|
|
bool sample_id_all __maybe_unused)
|
2010-04-02 04:59:21 +00:00
|
|
|
{
|
2011-01-29 16:01:45 +00:00
|
|
|
event->tracing_data.size = bswap_32(event->tracing_data.size);
|
2010-04-02 04:59:21 +00:00
|
|
|
}
|
|
|
|
|
2015-04-09 15:53:43 +00:00
|
|
|
static void perf_event__auxtrace_info_swap(union perf_event *event,
|
|
|
|
bool sample_id_all __maybe_unused)
|
|
|
|
{
|
|
|
|
size_t size;
|
|
|
|
|
|
|
|
event->auxtrace_info.type = bswap_32(event->auxtrace_info.type);
|
|
|
|
|
|
|
|
size = event->header.size;
|
|
|
|
size -= (void *)&event->auxtrace_info.priv - (void *)event;
|
|
|
|
mem_bswap_64(event->auxtrace_info.priv, size);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void perf_event__auxtrace_swap(union perf_event *event,
|
|
|
|
bool sample_id_all __maybe_unused)
|
|
|
|
{
|
|
|
|
event->auxtrace.size = bswap_64(event->auxtrace.size);
|
|
|
|
event->auxtrace.offset = bswap_64(event->auxtrace.offset);
|
|
|
|
event->auxtrace.reference = bswap_64(event->auxtrace.reference);
|
|
|
|
event->auxtrace.idx = bswap_32(event->auxtrace.idx);
|
|
|
|
event->auxtrace.tid = bswap_32(event->auxtrace.tid);
|
|
|
|
event->auxtrace.cpu = bswap_32(event->auxtrace.cpu);
|
|
|
|
}
|
|
|
|
|
2015-04-09 15:53:47 +00:00
|
|
|
static void perf_event__auxtrace_error_swap(union perf_event *event,
|
|
|
|
bool sample_id_all __maybe_unused)
|
|
|
|
{
|
|
|
|
event->auxtrace_error.type = bswap_32(event->auxtrace_error.type);
|
|
|
|
event->auxtrace_error.code = bswap_32(event->auxtrace_error.code);
|
|
|
|
event->auxtrace_error.cpu = bswap_32(event->auxtrace_error.cpu);
|
|
|
|
event->auxtrace_error.pid = bswap_32(event->auxtrace_error.pid);
|
|
|
|
event->auxtrace_error.tid = bswap_32(event->auxtrace_error.tid);
|
2019-02-06 10:39:47 +00:00
|
|
|
event->auxtrace_error.fmt = bswap_32(event->auxtrace_error.fmt);
|
2015-04-09 15:53:47 +00:00
|
|
|
event->auxtrace_error.ip = bswap_64(event->auxtrace_error.ip);
|
2019-02-06 10:39:47 +00:00
|
|
|
if (event->auxtrace_error.fmt)
|
|
|
|
event->auxtrace_error.time = bswap_64(event->auxtrace_error.time);
|
2015-04-09 15:53:47 +00:00
|
|
|
}
|
|
|
|
|
2015-10-25 14:51:19 +00:00
|
|
|
static void perf_event__thread_map_swap(union perf_event *event,
|
|
|
|
bool sample_id_all __maybe_unused)
|
|
|
|
{
|
|
|
|
unsigned i;
|
|
|
|
|
|
|
|
event->thread_map.nr = bswap_64(event->thread_map.nr);
|
|
|
|
|
|
|
|
for (i = 0; i < event->thread_map.nr; i++)
|
|
|
|
event->thread_map.entries[i].pid = bswap_64(event->thread_map.entries[i].pid);
|
|
|
|
}
|
|
|
|
|
2015-10-25 14:51:23 +00:00
|
|
|
static void perf_event__cpu_map_swap(union perf_event *event,
|
|
|
|
bool sample_id_all __maybe_unused)
|
|
|
|
{
|
2019-08-28 13:57:16 +00:00
|
|
|
struct perf_record_cpu_map_data *data = &event->cpu_map.data;
|
2015-10-25 14:51:23 +00:00
|
|
|
struct cpu_map_entries *cpus;
|
2019-08-28 13:57:16 +00:00
|
|
|
struct perf_record_record_cpu_map *mask;
|
2015-10-25 14:51:23 +00:00
|
|
|
unsigned i;
|
|
|
|
|
|
|
|
data->type = bswap_64(data->type);
|
|
|
|
|
|
|
|
switch (data->type) {
|
|
|
|
case PERF_CPU_MAP__CPUS:
|
|
|
|
cpus = (struct cpu_map_entries *)data->data;
|
|
|
|
|
|
|
|
cpus->nr = bswap_16(cpus->nr);
|
|
|
|
|
|
|
|
for (i = 0; i < cpus->nr; i++)
|
|
|
|
cpus->cpu[i] = bswap_16(cpus->cpu[i]);
|
|
|
|
break;
|
|
|
|
case PERF_CPU_MAP__MASK:
|
2019-08-28 13:57:16 +00:00
|
|
|
mask = (struct perf_record_record_cpu_map *)data->data;
|
2015-10-25 14:51:23 +00:00
|
|
|
|
|
|
|
mask->nr = bswap_16(mask->nr);
|
|
|
|
mask->long_size = bswap_16(mask->long_size);
|
|
|
|
|
|
|
|
switch (mask->long_size) {
|
|
|
|
case 4: mem_bswap_32(&mask->mask, mask->nr); break;
|
|
|
|
case 8: mem_bswap_64(&mask->mask, mask->nr); break;
|
|
|
|
default:
|
|
|
|
pr_err("cpu_map swap: unsupported long size\n");
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-10-25 14:51:27 +00:00
|
|
|
static void perf_event__stat_config_swap(union perf_event *event,
|
|
|
|
bool sample_id_all __maybe_unused)
|
|
|
|
{
|
|
|
|
u64 size;
|
|
|
|
|
|
|
|
size = event->stat_config.nr * sizeof(event->stat_config.data[0]);
|
|
|
|
size += 1; /* nr item itself */
|
|
|
|
mem_bswap_64(&event->stat_config.nr, size);
|
|
|
|
}
|
|
|
|
|
2015-10-25 14:51:30 +00:00
|
|
|
static void perf_event__stat_swap(union perf_event *event,
|
|
|
|
bool sample_id_all __maybe_unused)
|
|
|
|
{
|
|
|
|
event->stat.id = bswap_64(event->stat.id);
|
|
|
|
event->stat.thread = bswap_32(event->stat.thread);
|
|
|
|
event->stat.cpu = bswap_32(event->stat.cpu);
|
|
|
|
event->stat.val = bswap_64(event->stat.val);
|
|
|
|
event->stat.ena = bswap_64(event->stat.ena);
|
|
|
|
event->stat.run = bswap_64(event->stat.run);
|
|
|
|
}
|
|
|
|
|
2015-10-25 14:51:33 +00:00
|
|
|
static void perf_event__stat_round_swap(union perf_event *event,
|
|
|
|
bool sample_id_all __maybe_unused)
|
|
|
|
{
|
|
|
|
event->stat_round.type = bswap_64(event->stat_round.type);
|
|
|
|
event->stat_round.time = bswap_64(event->stat_round.time);
|
|
|
|
}
|
|
|
|
|
2012-05-30 12:23:43 +00:00
|
|
|
typedef void (*perf_event__swap_op)(union perf_event *event,
|
|
|
|
bool sample_id_all);
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
|
2011-01-29 16:01:45 +00:00
|
|
|
static perf_event__swap_op perf_event__swap_ops[] = {
|
|
|
|
[PERF_RECORD_MMAP] = perf_event__mmap_swap,
|
2013-08-21 10:10:25 +00:00
|
|
|
[PERF_RECORD_MMAP2] = perf_event__mmap2_swap,
|
2011-01-29 16:01:45 +00:00
|
|
|
[PERF_RECORD_COMM] = perf_event__comm_swap,
|
|
|
|
[PERF_RECORD_FORK] = perf_event__task_swap,
|
|
|
|
[PERF_RECORD_EXIT] = perf_event__task_swap,
|
|
|
|
[PERF_RECORD_LOST] = perf_event__all64_swap,
|
|
|
|
[PERF_RECORD_READ] = perf_event__read_swap,
|
2013-09-01 10:36:15 +00:00
|
|
|
[PERF_RECORD_THROTTLE] = perf_event__throttle_swap,
|
|
|
|
[PERF_RECORD_UNTHROTTLE] = perf_event__throttle_swap,
|
2011-01-29 16:01:45 +00:00
|
|
|
[PERF_RECORD_SAMPLE] = perf_event__all64_swap,
|
2015-04-30 14:37:29 +00:00
|
|
|
[PERF_RECORD_AUX] = perf_event__aux_swap,
|
2015-04-30 14:37:30 +00:00
|
|
|
[PERF_RECORD_ITRACE_START] = perf_event__itrace_start_swap,
|
2015-05-10 19:13:15 +00:00
|
|
|
[PERF_RECORD_LOST_SAMPLES] = perf_event__all64_swap,
|
2015-07-21 09:44:03 +00:00
|
|
|
[PERF_RECORD_SWITCH] = perf_event__switch_swap,
|
|
|
|
[PERF_RECORD_SWITCH_CPU_WIDE] = perf_event__switch_swap,
|
2019-05-22 05:32:49 +00:00
|
|
|
[PERF_RECORD_NAMESPACES] = perf_event__namespaces_swap,
|
2020-11-02 14:02:28 +00:00
|
|
|
[PERF_RECORD_CGROUP] = perf_event__cgroup_swap,
|
2020-05-12 12:19:18 +00:00
|
|
|
[PERF_RECORD_TEXT_POKE] = perf_event__text_poke_swap,
|
2011-07-15 18:34:09 +00:00
|
|
|
[PERF_RECORD_HEADER_ATTR] = perf_event__hdr_attr_swap,
|
2011-01-29 16:01:45 +00:00
|
|
|
[PERF_RECORD_HEADER_EVENT_TYPE] = perf_event__event_type_swap,
|
|
|
|
[PERF_RECORD_HEADER_TRACING_DATA] = perf_event__tracing_data_swap,
|
|
|
|
[PERF_RECORD_HEADER_BUILD_ID] = NULL,
|
2014-10-27 13:49:22 +00:00
|
|
|
[PERF_RECORD_ID_INDEX] = perf_event__all64_swap,
|
2015-04-09 15:53:43 +00:00
|
|
|
[PERF_RECORD_AUXTRACE_INFO] = perf_event__auxtrace_info_swap,
|
|
|
|
[PERF_RECORD_AUXTRACE] = perf_event__auxtrace_swap,
|
2015-04-09 15:53:47 +00:00
|
|
|
[PERF_RECORD_AUXTRACE_ERROR] = perf_event__auxtrace_error_swap,
|
2015-10-25 14:51:19 +00:00
|
|
|
[PERF_RECORD_THREAD_MAP] = perf_event__thread_map_swap,
|
2015-10-25 14:51:23 +00:00
|
|
|
[PERF_RECORD_CPU_MAP] = perf_event__cpu_map_swap,
|
2015-10-25 14:51:27 +00:00
|
|
|
[PERF_RECORD_STAT_CONFIG] = perf_event__stat_config_swap,
|
2015-10-25 14:51:30 +00:00
|
|
|
[PERF_RECORD_STAT] = perf_event__stat_swap,
|
2015-10-25 14:51:33 +00:00
|
|
|
[PERF_RECORD_STAT_ROUND] = perf_event__stat_round_swap,
|
2015-10-25 14:51:36 +00:00
|
|
|
[PERF_RECORD_EVENT_UPDATE] = perf_event__event_update_swap,
|
2016-03-08 08:38:44 +00:00
|
|
|
[PERF_RECORD_TIME_CONV] = perf_event__all64_swap,
|
2011-01-29 16:01:45 +00:00
|
|
|
[PERF_RECORD_HEADER_MAX] = NULL,
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
};
|
|
|
|
|
2010-05-03 13:14:33 +00:00
|
|
|
/*
|
|
|
|
* When perf record finishes a pass on every buffers, it records this pseudo
|
|
|
|
* event.
|
|
|
|
* We record the max timestamp t found in the pass n.
|
|
|
|
* Assuming these timestamps are monotonic across cpus, we know that if
|
|
|
|
* a buffer still has events with timestamps below t, they will be all
|
|
|
|
* available and then read in the pass n + 1.
|
|
|
|
* Hence when we start to read the pass n + 2, we can safely flush every
|
|
|
|
* events with timestamps below t.
|
|
|
|
*
|
|
|
|
* ============ PASS n =================
|
|
|
|
* CPU 0 | CPU 1
|
|
|
|
* |
|
|
|
|
* cnt1 timestamps | cnt2 timestamps
|
|
|
|
* 1 | 2
|
|
|
|
* 2 | 3
|
|
|
|
* - | 4 <--- max recorded
|
|
|
|
*
|
|
|
|
* ============ PASS n + 1 ==============
|
|
|
|
* CPU 0 | CPU 1
|
|
|
|
* |
|
|
|
|
* cnt1 timestamps | cnt2 timestamps
|
|
|
|
* 3 | 5
|
|
|
|
* 4 | 6
|
|
|
|
* 5 | 7 <---- max recorded
|
|
|
|
*
|
|
|
|
* Flush every events below timestamp 4
|
|
|
|
*
|
|
|
|
* ============ PASS n + 2 ==============
|
|
|
|
* CPU 0 | CPU 1
|
|
|
|
* |
|
|
|
|
* cnt1 timestamps | cnt2 timestamps
|
|
|
|
* 6 | 8
|
|
|
|
* 7 | 9
|
|
|
|
* - | 10
|
|
|
|
*
|
|
|
|
* Flush every events below timestamp 7
|
|
|
|
* etc...
|
|
|
|
*/
|
2015-03-03 14:58:45 +00:00
|
|
|
static int process_finished_round(struct perf_tool *tool __maybe_unused,
|
2012-09-10 22:15:03 +00:00
|
|
|
union perf_event *event __maybe_unused,
|
2015-03-03 15:37:54 +00:00
|
|
|
struct ordered_events *oe)
|
2010-05-03 13:14:33 +00:00
|
|
|
{
|
2015-06-23 07:52:48 +00:00
|
|
|
if (dump_trace)
|
|
|
|
fprintf(stdout, "\n");
|
2015-03-03 14:58:45 +00:00
|
|
|
return ordered_events__flush(oe, OE_FLUSH__ROUND);
|
2010-05-03 13:14:33 +00:00
|
|
|
}
|
|
|
|
|
2015-03-03 14:58:45 +00:00
|
|
|
int perf_session__queue_event(struct perf_session *s, union perf_event *event,
|
2017-08-03 11:24:33 +00:00
|
|
|
u64 timestamp, u64 file_offset)
|
2010-04-23 22:04:12 +00:00
|
|
|
{
|
2017-08-03 11:24:33 +00:00
|
|
|
return ordered_events__queue(&s->ordered_events, event, timestamp, file_offset);
|
perf session: Parse sample earlier
At perf_session__process_event, so that we reduce the number of lines in eache
tool sample processing routine that now receives a sample_data pointer already
parsed.
This will also be useful in the next patch, where we'll allow sample the
identity fields in MMAP, FORK, EXIT, etc, when it will be possible to see (cpu,
timestamp) just after before every event.
Also validate callchains in perf_session__process_event, i.e. as early as
possible, and keep a counter of the number of events discarded due to invalid
callchains, warning the user about it if it happens.
There is an assumption that was kept that all events have the same sample_type,
that will be dealt with in the future, when this preexisting limitation will be
removed.
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Ian Munsie <imunsie@au1.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <1291318772-30880-4-git-send-email-acme@infradead.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-12-02 16:10:21 +00:00
|
|
|
}
|
2010-04-23 22:04:12 +00:00
|
|
|
|
2015-01-05 18:23:05 +00:00
|
|
|
static void callchain__lbr_callstack_printf(struct perf_sample *sample)
|
perf session: Parse sample earlier
At perf_session__process_event, so that we reduce the number of lines in eache
tool sample processing routine that now receives a sample_data pointer already
parsed.
This will also be useful in the next patch, where we'll allow sample the
identity fields in MMAP, FORK, EXIT, etc, when it will be possible to see (cpu,
timestamp) just after before every event.
Also validate callchains in perf_session__process_event, i.e. as early as
possible, and keep a counter of the number of events discarded due to invalid
callchains, warning the user about it if it happens.
There is an assumption that was kept that all events have the same sample_type,
that will be dealt with in the future, when this preexisting limitation will be
removed.
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Ian Munsie <imunsie@au1.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <1291318772-30880-4-git-send-email-acme@infradead.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-12-02 16:10:21 +00:00
|
|
|
{
|
2015-01-05 18:23:05 +00:00
|
|
|
struct ip_callchain *callchain = sample->callchain;
|
|
|
|
struct branch_stack *lbr_stack = sample->branch_stack;
|
2020-02-28 16:30:00 +00:00
|
|
|
struct branch_entry *entries = perf_sample__branch_entries(sample);
|
2015-01-05 18:23:05 +00:00
|
|
|
u64 kernel_callchain_nr = callchain->nr;
|
perf session: Parse sample earlier
At perf_session__process_event, so that we reduce the number of lines in eache
tool sample processing routine that now receives a sample_data pointer already
parsed.
This will also be useful in the next patch, where we'll allow sample the
identity fields in MMAP, FORK, EXIT, etc, when it will be possible to see (cpu,
timestamp) just after before every event.
Also validate callchains in perf_session__process_event, i.e. as early as
possible, and keep a counter of the number of events discarded due to invalid
callchains, warning the user about it if it happens.
There is an assumption that was kept that all events have the same sample_type,
that will be dealt with in the future, when this preexisting limitation will be
removed.
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Ian Munsie <imunsie@au1.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <1291318772-30880-4-git-send-email-acme@infradead.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-12-02 16:10:21 +00:00
|
|
|
unsigned int i;
|
2010-04-23 22:04:12 +00:00
|
|
|
|
2015-01-05 18:23:05 +00:00
|
|
|
for (i = 0; i < kernel_callchain_nr; i++) {
|
|
|
|
if (callchain->ips[i] == PERF_CONTEXT_USER)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((i != kernel_callchain_nr) && lbr_stack->nr) {
|
|
|
|
u64 total_nr;
|
|
|
|
/*
|
|
|
|
* LBR callstack can only get user call chain,
|
|
|
|
* i is kernel call chain number,
|
|
|
|
* 1 is PERF_CONTEXT_USER.
|
|
|
|
*
|
|
|
|
* The user call chain is stored in LBR registers.
|
|
|
|
* LBR are pair registers. The caller is stored
|
|
|
|
* in "from" register, while the callee is stored
|
|
|
|
* in "to" register.
|
|
|
|
* For example, there is a call stack
|
|
|
|
* "A"->"B"->"C"->"D".
|
|
|
|
* The LBR registers will recorde like
|
|
|
|
* "C"->"D", "B"->"C", "A"->"B".
|
|
|
|
* So only the first "to" register and all "from"
|
|
|
|
* registers are needed to construct the whole stack.
|
|
|
|
*/
|
|
|
|
total_nr = i + 1 + lbr_stack->nr + 1;
|
|
|
|
kernel_callchain_nr = i + 1;
|
|
|
|
|
|
|
|
printf("... LBR call chain: nr:%" PRIu64 "\n", total_nr);
|
|
|
|
|
|
|
|
for (i = 0; i < kernel_callchain_nr; i++)
|
|
|
|
printf("..... %2d: %016" PRIx64 "\n",
|
|
|
|
i, callchain->ips[i]);
|
|
|
|
|
|
|
|
printf("..... %2d: %016" PRIx64 "\n",
|
2020-02-28 16:30:00 +00:00
|
|
|
(int)(kernel_callchain_nr), entries[0].to);
|
2015-01-05 18:23:05 +00:00
|
|
|
for (i = 0; i < lbr_stack->nr; i++)
|
|
|
|
printf("..... %2d: %016" PRIx64 "\n",
|
2020-02-28 16:30:00 +00:00
|
|
|
(int)(i + kernel_callchain_nr + 1), entries[i].from);
|
2015-01-05 18:23:05 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-07-21 11:23:51 +00:00
|
|
|
static void callchain__printf(struct evsel *evsel,
|
2015-01-05 18:23:05 +00:00
|
|
|
struct perf_sample *sample)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
struct ip_callchain *callchain = sample->callchain;
|
|
|
|
|
2020-04-30 14:19:45 +00:00
|
|
|
if (evsel__has_branch_callstack(evsel))
|
2015-01-05 18:23:05 +00:00
|
|
|
callchain__lbr_callstack_printf(sample);
|
|
|
|
|
|
|
|
printf("... FP chain: nr:%" PRIu64 "\n", callchain->nr);
|
perf session: Parse sample earlier
At perf_session__process_event, so that we reduce the number of lines in eache
tool sample processing routine that now receives a sample_data pointer already
parsed.
This will also be useful in the next patch, where we'll allow sample the
identity fields in MMAP, FORK, EXIT, etc, when it will be possible to see (cpu,
timestamp) just after before every event.
Also validate callchains in perf_session__process_event, i.e. as early as
possible, and keep a counter of the number of events discarded due to invalid
callchains, warning the user about it if it happens.
There is an assumption that was kept that all events have the same sample_type,
that will be dealt with in the future, when this preexisting limitation will be
removed.
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Ian Munsie <imunsie@au1.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <1291318772-30880-4-git-send-email-acme@infradead.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-12-02 16:10:21 +00:00
|
|
|
|
2015-01-05 18:23:05 +00:00
|
|
|
for (i = 0; i < callchain->nr; i++)
|
2011-01-22 22:37:02 +00:00
|
|
|
printf("..... %2d: %016" PRIx64 "\n",
|
2015-01-05 18:23:05 +00:00
|
|
|
i, callchain->ips[i]);
|
2010-04-23 22:04:12 +00:00
|
|
|
}
|
|
|
|
|
2019-08-09 15:26:30 +00:00
|
|
|
static void branch_stack__printf(struct perf_sample *sample, bool callstack)
|
2012-02-09 22:21:01 +00:00
|
|
|
{
|
2020-02-28 16:30:00 +00:00
|
|
|
struct branch_entry *entries = perf_sample__branch_entries(sample);
|
2012-02-09 22:21:01 +00:00
|
|
|
uint64_t i;
|
|
|
|
|
2019-08-09 15:26:30 +00:00
|
|
|
printf("%s: nr:%" PRIu64 "\n",
|
|
|
|
!callstack ? "... branch stack" : "... branch callstack",
|
|
|
|
sample->branch_stack->nr);
|
2012-02-09 22:21:01 +00:00
|
|
|
|
2015-07-18 15:24:46 +00:00
|
|
|
for (i = 0; i < sample->branch_stack->nr; i++) {
|
2020-02-28 16:30:00 +00:00
|
|
|
struct branch_entry *e = &entries[i];
|
2015-07-18 15:24:46 +00:00
|
|
|
|
2019-08-09 15:26:30 +00:00
|
|
|
if (!callstack) {
|
|
|
|
printf("..... %2"PRIu64": %016" PRIx64 " -> %016" PRIx64 " %hu cycles %s%s%s%s %x\n",
|
|
|
|
i, e->from, e->to,
|
|
|
|
(unsigned short)e->flags.cycles,
|
|
|
|
e->flags.mispred ? "M" : " ",
|
|
|
|
e->flags.predicted ? "P" : " ",
|
|
|
|
e->flags.abort ? "A" : " ",
|
|
|
|
e->flags.in_tx ? "T" : " ",
|
|
|
|
(unsigned)e->flags.reserved);
|
|
|
|
} else {
|
|
|
|
printf("..... %2"PRIu64": %016" PRIx64 "\n",
|
|
|
|
i, i > 0 ? e->from : e->to);
|
|
|
|
}
|
2015-07-18 15:24:46 +00:00
|
|
|
}
|
2012-02-09 22:21:01 +00:00
|
|
|
}
|
|
|
|
|
2012-08-07 13:20:45 +00:00
|
|
|
static void regs_dump__printf(u64 mask, u64 *regs)
|
|
|
|
{
|
|
|
|
unsigned rid, i = 0;
|
|
|
|
|
|
|
|
for_each_set_bit(rid, (unsigned long *) &mask, sizeof(mask) * 8) {
|
|
|
|
u64 val = regs[i++];
|
|
|
|
|
perf script: Better align register values in dump
Before:
$ perf script --dump-raw-trace
[...]
2492031077254920 0x1e08 [0x308]: PERF_RECORD_SAMPLE(IP, 0x1): 47557/47557: 0xc00000000012eeb0 period: 1 addr: 0
... user regs: mask 0x1fffffffffff ABI 64-bit
.... r0 0xb
.... r1 0x7ffff3b90fa0
.... r2 0x7fffbabf7300
.... r3 0x7ffff3b9ed60
.... r4 0x7ffff3b95cc0
.... r5 0x1000c5a2940
.... r6 0xfefefefefefefeff
.... r7 0x7f7f7f7f7f7f7f7f
.... r8 0x7ffff3b9ed60
.... r9 0x0
[...]
After:
[...]
2492031077254920 0x1e08 [0x308]: PERF_RECORD_SAMPLE(IP, 0x1): 47557/47557: 0xc00000000012eeb0 period: 1 addr: 0
... user regs: mask 0x1fffffffffff ABI 64-bit
.... r0 0x000000000000000b
.... r1 0x00007ffff3b90fa0
.... r2 0x00007fffbabf7300
.... r3 0x00007ffff3b9ed60
.... r4 0x00007ffff3b95cc0
.... r5 0x000001000c5a2940
.... r6 0xfefefefefefefeff
.... r7 0x7f7f7f7f7f7f7f7f
.... r8 0x00007ffff3b9ed60
.... r9 0x0000000000000000
[...]
Committer testing:
Full set of instructions, testing on x86_64:
# perf record -I
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 2.855 MB perf.data (4902 samples) ]
# perf evlist -v
cycles: size: 120, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|ID|CPU|PERIOD|REGS_INTR, read_format: ID, disabled: 1, inherit: 1, freq: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, sample_regs_intr: 0xff0fff
dummy:HG: type: 1, size: 120, config: 0x9, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|ID|CPU|PERIOD|REGS_INTR, read_format: ID, inherit: 1, mmap: 1, comm: 1, freq: 1, task: 1, sample_id_all: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1, sample_regs_intr: 0xff0fff
#
Before:
# perf script --dump-raw-trace
[...]
0 1542674658099675 0x1cb700 [0xe0]: PERF_RECORD_SAMPLE(IP, 0x4001): 1825/1825: 0xffffffff9506e544 period: 1 addr: 0
... intr regs: mask 0xff0fff ABI 64-bit
.... AX 0xf
.... BX 0xffff96e1064125a0
.... CX 0x38f
.... DX 0x7
.... SI 0xf
.... DI 0x38f
.... BP 0x1
.... SP 0xfffffe000000bdf0
.... IP 0xffffffff9506e544
.... FLAGS 0xa
.... CS 0x10
.... SS 0x18
.... R8 0x0
.... R9 0x0
.... R10 0xfffffe00000260c8
.... R11 0xfffffe000000bef8
.... R12 0x1
.... R13 0x64
.... R14 0x390
.... R15 0xffff96e1064125a0
... thread: perf:1825
...... dso: /proc/kcore
perf 1825 [000] 1542674.658099: 1 cycles: ffffffff9506e544 native_write_msr+0x4 (vmlinux
[...]
After:
# perf script --dump-raw-trace
[...]
0 1542674658096068 0x1cb620 [0xe0]: PERF_RECORD_SAMPLE(IP, 0x4001): 1825/1825: 0xffffffff9506e544 period: 1 addr: 0
... intr regs: mask 0xff0fff ABI 64-bit
.... AX 0x000000000000000f
.... BX 0xffff96e1064125a0
.... CX 0x000000000000038f
.... DX 0x0000000000000007
.... SI 0x000000000000000f
.... DI 0x000000000000038f
.... BP 0x0000000000000000
.... SP 0xffffb3e788fb7c20
.... IP 0xffffffff9506e544
.... FLAGS 0x000000000000000a
.... CS 0x0000000000000010
.... SS 0x0000000000000018
.... R8 0x00057b0deeffdfe3
.... R9 0xffff96e106432480
.... R10 0x0000000000000000
.... R11 0xffff96e106412cc0
.... R12 0xffffb3e788fb7d00
.... R13 0xffff96e106432408
.... R14 0xffff96e106432400
.... R15 0xffff96e0e09a4800
... thread: perf:1825
...... dso: /proc/kcore
perf 1825 [000] 1542674.658096: 1 cycles: ffffffff9506e544 native_write_msr+0x4 (vmlinux)
[...]
Signed-off-by: Paul Clarke <pc@us.ibm.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jin Yao <yao.jin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
LPU-Reference: 1589911102-9460-1-git-send-email-pc@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-05-19 17:58:22 +00:00
|
|
|
printf(".... %-5s 0x%016" PRIx64 "\n",
|
2012-08-07 13:20:45 +00:00
|
|
|
perf_reg_name(rid), val);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-09-24 11:48:39 +00:00
|
|
|
static const char *regs_abi[] = {
|
|
|
|
[PERF_SAMPLE_REGS_ABI_NONE] = "none",
|
|
|
|
[PERF_SAMPLE_REGS_ABI_32] = "32-bit",
|
|
|
|
[PERF_SAMPLE_REGS_ABI_64] = "64-bit",
|
|
|
|
};
|
|
|
|
|
|
|
|
static inline const char *regs_dump_abi(struct regs_dump *d)
|
|
|
|
{
|
|
|
|
if (d->abi > PERF_SAMPLE_REGS_ABI_64)
|
|
|
|
return "unknown";
|
|
|
|
|
|
|
|
return regs_abi[d->abi];
|
|
|
|
}
|
|
|
|
|
|
|
|
static void regs__printf(const char *type, struct regs_dump *regs)
|
|
|
|
{
|
|
|
|
u64 mask = regs->mask;
|
|
|
|
|
|
|
|
printf("... %s regs: mask 0x%" PRIx64 " ABI %s\n",
|
|
|
|
type,
|
|
|
|
mask,
|
|
|
|
regs_dump_abi(regs));
|
|
|
|
|
|
|
|
regs_dump__printf(mask, regs->regs);
|
|
|
|
}
|
|
|
|
|
2014-01-07 12:47:25 +00:00
|
|
|
static void regs_user__printf(struct perf_sample *sample)
|
2012-08-07 13:20:45 +00:00
|
|
|
{
|
|
|
|
struct regs_dump *user_regs = &sample->user_regs;
|
|
|
|
|
2014-09-24 11:48:39 +00:00
|
|
|
if (user_regs->regs)
|
|
|
|
regs__printf("user", user_regs);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void regs_intr__printf(struct perf_sample *sample)
|
|
|
|
{
|
|
|
|
struct regs_dump *intr_regs = &sample->intr_regs;
|
|
|
|
|
|
|
|
if (intr_regs->regs)
|
|
|
|
regs__printf("intr", intr_regs);
|
2012-08-07 13:20:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void stack_user__printf(struct stack_dump *dump)
|
|
|
|
{
|
|
|
|
printf("... ustack: size %" PRIu64 ", offset 0x%x\n",
|
|
|
|
dump->size, dump->offset);
|
|
|
|
}
|
|
|
|
|
2020-11-30 17:55:12 +00:00
|
|
|
static void evlist__print_tstamp(struct evlist *evlist, union perf_event *event, struct perf_sample *sample)
|
2010-12-02 12:25:28 +00:00
|
|
|
{
|
2020-06-17 12:24:21 +00:00
|
|
|
u64 sample_type = __evlist__combined_sample_type(evlist);
|
2012-08-01 22:15:52 +00:00
|
|
|
|
2010-12-02 12:25:28 +00:00
|
|
|
if (event->header.type != PERF_RECORD_SAMPLE &&
|
2020-06-17 12:29:48 +00:00
|
|
|
!evlist__sample_id_all(evlist)) {
|
2010-12-02 12:25:28 +00:00
|
|
|
fputs("-1 -1 ", stdout);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-08-01 22:15:52 +00:00
|
|
|
if ((sample_type & PERF_SAMPLE_CPU))
|
2010-12-02 12:25:28 +00:00
|
|
|
printf("%u ", sample->cpu);
|
|
|
|
|
2012-08-01 22:15:52 +00:00
|
|
|
if (sample_type & PERF_SAMPLE_TIME)
|
2011-01-22 22:37:02 +00:00
|
|
|
printf("%" PRIu64 " ", sample->time);
|
2010-12-02 12:25:28 +00:00
|
|
|
}
|
|
|
|
|
2012-10-10 15:38:13 +00:00
|
|
|
static void sample_read__printf(struct perf_sample *sample, u64 read_format)
|
|
|
|
{
|
|
|
|
printf("... sample_read:\n");
|
|
|
|
|
|
|
|
if (read_format & PERF_FORMAT_TOTAL_TIME_ENABLED)
|
|
|
|
printf("...... time enabled %016" PRIx64 "\n",
|
|
|
|
sample->read.time_enabled);
|
|
|
|
|
|
|
|
if (read_format & PERF_FORMAT_TOTAL_TIME_RUNNING)
|
|
|
|
printf("...... time running %016" PRIx64 "\n",
|
|
|
|
sample->read.time_running);
|
|
|
|
|
|
|
|
if (read_format & PERF_FORMAT_GROUP) {
|
|
|
|
u64 i;
|
|
|
|
|
|
|
|
printf(".... group nr %" PRIu64 "\n", sample->read.group.nr);
|
|
|
|
|
|
|
|
for (i = 0; i < sample->read.group.nr; i++) {
|
|
|
|
struct sample_read_value *value;
|
|
|
|
|
|
|
|
value = &sample->read.group.values[i];
|
|
|
|
printf("..... id %016" PRIx64
|
|
|
|
", value %016" PRIx64 "\n",
|
|
|
|
value->id, value->value);
|
|
|
|
}
|
|
|
|
} else
|
|
|
|
printf("..... id %016" PRIx64 ", value %016" PRIx64 "\n",
|
|
|
|
sample->read.one.id, sample->read.one.value);
|
|
|
|
}
|
|
|
|
|
2019-07-21 11:23:52 +00:00
|
|
|
static void dump_event(struct evlist *evlist, union perf_event *event,
|
2011-01-29 15:02:00 +00:00
|
|
|
u64 file_offset, struct perf_sample *sample)
|
2010-12-07 12:48:47 +00:00
|
|
|
{
|
|
|
|
if (!dump_trace)
|
|
|
|
return;
|
|
|
|
|
2011-01-22 22:37:02 +00:00
|
|
|
printf("\n%#" PRIx64 " [%#x]: event: %d\n",
|
|
|
|
file_offset, event->header.size, event->header.type);
|
2010-12-07 12:48:47 +00:00
|
|
|
|
|
|
|
trace_event(event);
|
2019-01-17 13:37:17 +00:00
|
|
|
if (event->header.type == PERF_RECORD_SAMPLE && evlist->trace_event_sample_raw)
|
|
|
|
evlist->trace_event_sample_raw(evlist, event, sample);
|
2010-12-07 12:48:47 +00:00
|
|
|
|
|
|
|
if (sample)
|
2020-11-30 17:55:12 +00:00
|
|
|
evlist__print_tstamp(evlist, event, sample);
|
2010-12-07 12:48:47 +00:00
|
|
|
|
2011-01-22 22:37:02 +00:00
|
|
|
printf("%#" PRIx64 " [%#x]: PERF_RECORD_%s", file_offset,
|
2011-01-29 16:01:45 +00:00
|
|
|
event->header.size, perf_event__name(event->header.type));
|
2010-12-07 12:48:47 +00:00
|
|
|
}
|
|
|
|
|
2020-12-16 18:57:57 +00:00
|
|
|
char *get_page_size_name(u64 size, char *str)
|
|
|
|
{
|
|
|
|
if (!size || !unit_number__scnprintf(str, PAGE_SIZE_NAME_LEN, size))
|
|
|
|
snprintf(str, PAGE_SIZE_NAME_LEN, "%s", "N/A");
|
|
|
|
|
|
|
|
return str;
|
|
|
|
}
|
|
|
|
|
2019-07-21 11:23:51 +00:00
|
|
|
static void dump_sample(struct evsel *evsel, union perf_event *event,
|
2011-01-29 15:02:00 +00:00
|
|
|
struct perf_sample *sample)
|
2010-12-07 12:48:47 +00:00
|
|
|
{
|
2012-08-01 22:15:52 +00:00
|
|
|
u64 sample_type;
|
2020-12-16 18:57:57 +00:00
|
|
|
char str[PAGE_SIZE_NAME_LEN];
|
2012-08-01 22:15:52 +00:00
|
|
|
|
2010-12-09 14:20:20 +00:00
|
|
|
if (!dump_trace)
|
|
|
|
return;
|
|
|
|
|
2014-02-26 03:43:46 +00:00
|
|
|
printf("(IP, 0x%x): %d/%d: %#" PRIx64 " period: %" PRIu64 " addr: %#" PRIx64 "\n",
|
2011-01-22 22:37:02 +00:00
|
|
|
event->header.misc, sample->pid, sample->tid, sample->ip,
|
2011-05-30 19:08:23 +00:00
|
|
|
sample->period, sample->addr);
|
2010-12-07 12:48:47 +00:00
|
|
|
|
2019-07-21 11:24:29 +00:00
|
|
|
sample_type = evsel->core.attr.sample_type;
|
2012-08-01 22:15:52 +00:00
|
|
|
|
2018-05-28 19:00:29 +00:00
|
|
|
if (evsel__has_callchain(evsel))
|
2015-01-05 18:23:05 +00:00
|
|
|
callchain__printf(evsel, sample);
|
2012-02-09 22:21:01 +00:00
|
|
|
|
2020-04-29 15:07:47 +00:00
|
|
|
if (evsel__has_br_stack(evsel))
|
2020-04-30 14:19:45 +00:00
|
|
|
branch_stack__printf(sample, evsel__has_branch_callstack(evsel));
|
2012-08-07 13:20:45 +00:00
|
|
|
|
|
|
|
if (sample_type & PERF_SAMPLE_REGS_USER)
|
2014-01-07 12:47:25 +00:00
|
|
|
regs_user__printf(sample);
|
2012-08-07 13:20:45 +00:00
|
|
|
|
2014-09-24 11:48:39 +00:00
|
|
|
if (sample_type & PERF_SAMPLE_REGS_INTR)
|
|
|
|
regs_intr__printf(sample);
|
|
|
|
|
2012-08-07 13:20:45 +00:00
|
|
|
if (sample_type & PERF_SAMPLE_STACK_USER)
|
|
|
|
stack_user__printf(&sample->user_stack);
|
2013-01-24 15:10:29 +00:00
|
|
|
|
2021-02-02 20:09:10 +00:00
|
|
|
if (sample_type & PERF_SAMPLE_WEIGHT_TYPE) {
|
|
|
|
printf("... weight: %" PRIu64 "", sample->weight);
|
|
|
|
if (sample_type & PERF_SAMPLE_WEIGHT_STRUCT)
|
|
|
|
printf(",0x%"PRIx16"", sample->ins_lat);
|
|
|
|
printf("\n");
|
|
|
|
}
|
2013-01-24 15:10:35 +00:00
|
|
|
|
|
|
|
if (sample_type & PERF_SAMPLE_DATA_SRC)
|
|
|
|
printf(" . data_src: 0x%"PRIx64"\n", sample->data_src);
|
2012-10-10 15:38:13 +00:00
|
|
|
|
2017-08-29 17:11:09 +00:00
|
|
|
if (sample_type & PERF_SAMPLE_PHYS_ADDR)
|
|
|
|
printf(" .. phys_addr: 0x%"PRIx64"\n", sample->phys_addr);
|
|
|
|
|
2020-12-16 18:57:57 +00:00
|
|
|
if (sample_type & PERF_SAMPLE_DATA_PAGE_SIZE)
|
|
|
|
printf(" .. data page size: %s\n", get_page_size_name(sample->data_page_size, str));
|
|
|
|
|
2021-01-05 19:57:50 +00:00
|
|
|
if (sample_type & PERF_SAMPLE_CODE_PAGE_SIZE)
|
|
|
|
printf(" .. code page size: %s\n", get_page_size_name(sample->code_page_size, str));
|
|
|
|
|
2013-09-20 14:40:43 +00:00
|
|
|
if (sample_type & PERF_SAMPLE_TRANSACTION)
|
|
|
|
printf("... transaction: %" PRIx64 "\n", sample->transaction);
|
|
|
|
|
2012-10-10 15:38:13 +00:00
|
|
|
if (sample_type & PERF_SAMPLE_READ)
|
2019-07-21 11:24:29 +00:00
|
|
|
sample_read__printf(sample, evsel->core.attr.read_format);
|
2010-12-07 12:48:47 +00:00
|
|
|
}
|
|
|
|
|
2019-07-21 11:23:51 +00:00
|
|
|
static void dump_read(struct evsel *evsel, union perf_event *event)
|
2017-08-24 16:27:32 +00:00
|
|
|
{
|
2019-08-26 22:02:31 +00:00
|
|
|
struct perf_record_read *read_event = &event->read;
|
2017-08-24 16:27:32 +00:00
|
|
|
u64 read_format;
|
|
|
|
|
|
|
|
if (!dump_trace)
|
|
|
|
return;
|
|
|
|
|
2019-08-25 18:17:48 +00:00
|
|
|
printf(": %d %d %s %" PRI_lu64 "\n", event->read.pid, event->read.tid,
|
2020-04-29 19:07:09 +00:00
|
|
|
evsel__name(evsel), event->read.value);
|
2017-08-24 16:27:32 +00:00
|
|
|
|
2019-07-02 10:34:17 +00:00
|
|
|
if (!evsel)
|
|
|
|
return;
|
|
|
|
|
2019-07-21 11:24:29 +00:00
|
|
|
read_format = evsel->core.attr.read_format;
|
2017-08-24 16:27:32 +00:00
|
|
|
|
|
|
|
if (read_format & PERF_FORMAT_TOTAL_TIME_ENABLED)
|
2019-08-25 18:17:48 +00:00
|
|
|
printf("... time enabled : %" PRI_lu64 "\n", read_event->time_enabled);
|
2017-08-24 16:27:32 +00:00
|
|
|
|
|
|
|
if (read_format & PERF_FORMAT_TOTAL_TIME_RUNNING)
|
2019-08-25 18:17:48 +00:00
|
|
|
printf("... time running : %" PRI_lu64 "\n", read_event->time_running);
|
2017-08-24 16:27:32 +00:00
|
|
|
|
|
|
|
if (read_format & PERF_FORMAT_ID)
|
2019-08-25 18:17:48 +00:00
|
|
|
printf("... id : %" PRI_lu64 "\n", read_event->id);
|
2017-08-24 16:27:32 +00:00
|
|
|
}
|
|
|
|
|
2015-02-14 17:26:15 +00:00
|
|
|
static struct machine *machines__find_for_cpumode(struct machines *machines,
|
2013-08-27 08:23:06 +00:00
|
|
|
union perf_event *event,
|
|
|
|
struct perf_sample *sample)
|
2011-11-28 09:56:39 +00:00
|
|
|
{
|
2012-07-20 23:25:48 +00:00
|
|
|
if (perf_guest &&
|
2016-03-22 21:23:43 +00:00
|
|
|
((sample->cpumode == PERF_RECORD_MISC_GUEST_KERNEL) ||
|
|
|
|
(sample->cpumode == PERF_RECORD_MISC_GUEST_USER))) {
|
2012-04-09 08:22:23 +00:00
|
|
|
u32 pid;
|
|
|
|
|
2013-08-21 10:10:25 +00:00
|
|
|
if (event->header.type == PERF_RECORD_MMAP
|
|
|
|
|| event->header.type == PERF_RECORD_MMAP2)
|
2012-04-09 08:22:23 +00:00
|
|
|
pid = event->mmap.pid;
|
|
|
|
else
|
2013-08-27 08:23:06 +00:00
|
|
|
pid = sample->pid;
|
2012-04-09 08:22:23 +00:00
|
|
|
|
2021-02-18 09:57:55 +00:00
|
|
|
return machines__find_guest(machines, pid);
|
2012-04-09 08:22:23 +00:00
|
|
|
}
|
2011-11-28 09:56:39 +00:00
|
|
|
|
2015-02-14 17:26:15 +00:00
|
|
|
return &machines->host;
|
2011-11-28 09:56:39 +00:00
|
|
|
}
|
|
|
|
|
2019-07-21 11:23:52 +00:00
|
|
|
static int deliver_sample_value(struct evlist *evlist,
|
2012-10-10 16:52:24 +00:00
|
|
|
struct perf_tool *tool,
|
|
|
|
union perf_event *event,
|
|
|
|
struct perf_sample *sample,
|
|
|
|
struct sample_read_value *v,
|
|
|
|
struct machine *machine)
|
|
|
|
{
|
2020-11-30 17:17:57 +00:00
|
|
|
struct perf_sample_id *sid = evlist__id2sid(evlist, v->id);
|
2019-09-03 08:34:29 +00:00
|
|
|
struct evsel *evsel;
|
2012-10-10 16:52:24 +00:00
|
|
|
|
|
|
|
if (sid) {
|
|
|
|
sample->id = v->id;
|
|
|
|
sample->period = v->value - sid->period;
|
|
|
|
sid->period = v->value;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!sid || sid->evsel == NULL) {
|
2015-02-14 18:05:28 +00:00
|
|
|
++evlist->stats.nr_unknown_id;
|
2012-10-10 16:52:24 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-20 12:27:55 +00:00
|
|
|
/*
|
|
|
|
* There's no reason to deliver sample
|
|
|
|
* for zero period, bail out.
|
|
|
|
*/
|
|
|
|
if (!sample->period)
|
|
|
|
return 0;
|
|
|
|
|
2019-09-03 08:34:29 +00:00
|
|
|
evsel = container_of(sid->evsel, struct evsel, core);
|
|
|
|
return tool->sample(tool, event, sample, evsel, machine);
|
2012-10-10 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
2019-07-21 11:23:52 +00:00
|
|
|
static int deliver_sample_group(struct evlist *evlist,
|
2012-10-10 16:52:24 +00:00
|
|
|
struct perf_tool *tool,
|
|
|
|
union perf_event *event,
|
|
|
|
struct perf_sample *sample,
|
|
|
|
struct machine *machine)
|
|
|
|
{
|
|
|
|
int ret = -EINVAL;
|
|
|
|
u64 i;
|
|
|
|
|
|
|
|
for (i = 0; i < sample->read.group.nr; i++) {
|
2015-02-14 18:05:28 +00:00
|
|
|
ret = deliver_sample_value(evlist, tool, event, sample,
|
2012-10-10 16:52:24 +00:00
|
|
|
&sample->read.group.values[i],
|
|
|
|
machine);
|
|
|
|
if (ret)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-11-30 18:16:29 +00:00
|
|
|
static int evlist__deliver_sample(struct evlist *evlist, struct perf_tool *tool,
|
|
|
|
union perf_event *event, struct perf_sample *sample,
|
|
|
|
struct evsel *evsel, struct machine *machine)
|
2012-10-10 16:52:24 +00:00
|
|
|
{
|
|
|
|
/* We know evsel != NULL. */
|
2019-07-21 11:24:29 +00:00
|
|
|
u64 sample_type = evsel->core.attr.sample_type;
|
|
|
|
u64 read_format = evsel->core.attr.read_format;
|
2012-10-10 16:52:24 +00:00
|
|
|
|
2017-01-17 13:22:33 +00:00
|
|
|
/* Standard sample delivery. */
|
2012-10-10 16:52:24 +00:00
|
|
|
if (!(sample_type & PERF_SAMPLE_READ))
|
|
|
|
return tool->sample(tool, event, sample, evsel, machine);
|
|
|
|
|
|
|
|
/* For PERF_SAMPLE_READ we have either single or group mode. */
|
|
|
|
if (read_format & PERF_FORMAT_GROUP)
|
2015-02-14 18:05:28 +00:00
|
|
|
return deliver_sample_group(evlist, tool, event, sample,
|
2012-10-10 16:52:24 +00:00
|
|
|
machine);
|
|
|
|
else
|
2015-02-14 18:05:28 +00:00
|
|
|
return deliver_sample_value(evlist, tool, event, sample,
|
2012-10-10 16:52:24 +00:00
|
|
|
&sample->read.one, machine);
|
|
|
|
}
|
|
|
|
|
2015-03-03 15:20:38 +00:00
|
|
|
static int machines__deliver_event(struct machines *machines,
|
2019-07-21 11:23:52 +00:00
|
|
|
struct evlist *evlist,
|
2015-03-03 15:20:38 +00:00
|
|
|
union perf_event *event,
|
|
|
|
struct perf_sample *sample,
|
|
|
|
struct perf_tool *tool, u64 file_offset)
|
2010-12-05 13:32:55 +00:00
|
|
|
{
|
2019-07-21 11:23:51 +00:00
|
|
|
struct evsel *evsel;
|
2011-11-28 09:56:39 +00:00
|
|
|
struct machine *machine;
|
2011-03-15 18:44:01 +00:00
|
|
|
|
2015-02-14 18:08:51 +00:00
|
|
|
dump_event(evlist, event, file_offset, sample);
|
2010-12-07 12:48:55 +00:00
|
|
|
|
2020-11-30 17:17:57 +00:00
|
|
|
evsel = evlist__id2evsel(evlist, sample->id);
|
2011-10-29 14:15:04 +00:00
|
|
|
|
2015-03-03 14:48:12 +00:00
|
|
|
machine = machines__find_for_cpumode(machines, event, sample);
|
2011-11-28 09:56:39 +00:00
|
|
|
|
2010-12-05 13:32:55 +00:00
|
|
|
switch (event->header.type) {
|
|
|
|
case PERF_RECORD_SAMPLE:
|
2011-03-15 18:44:01 +00:00
|
|
|
if (evsel == NULL) {
|
2015-02-14 18:05:28 +00:00
|
|
|
++evlist->stats.nr_unknown_id;
|
2012-04-12 12:21:01 +00:00
|
|
|
return 0;
|
2011-03-15 18:44:01 +00:00
|
|
|
}
|
2015-09-03 12:31:00 +00:00
|
|
|
dump_sample(evsel, event, sample);
|
2012-02-10 17:05:04 +00:00
|
|
|
if (machine == NULL) {
|
2015-02-14 18:05:28 +00:00
|
|
|
++evlist->stats.nr_unprocessable_samples;
|
2012-04-12 12:21:01 +00:00
|
|
|
return 0;
|
2012-02-10 17:05:04 +00:00
|
|
|
}
|
2020-11-30 18:16:29 +00:00
|
|
|
return evlist__deliver_sample(evlist, tool, event, sample, evsel, machine);
|
2010-12-05 13:32:55 +00:00
|
|
|
case PERF_RECORD_MMAP:
|
2011-11-28 10:30:20 +00:00
|
|
|
return tool->mmap(tool, event, sample, machine);
|
2013-08-21 10:10:25 +00:00
|
|
|
case PERF_RECORD_MMAP2:
|
2015-06-17 13:51:10 +00:00
|
|
|
if (event->header.misc & PERF_RECORD_MISC_PROC_MAP_PARSE_TIMEOUT)
|
|
|
|
++evlist->stats.nr_proc_map_timeout;
|
2013-08-21 10:10:25 +00:00
|
|
|
return tool->mmap2(tool, event, sample, machine);
|
2010-12-05 13:32:55 +00:00
|
|
|
case PERF_RECORD_COMM:
|
2011-11-28 10:30:20 +00:00
|
|
|
return tool->comm(tool, event, sample, machine);
|
perf tools: Add PERF_RECORD_NAMESPACES to include namespaces related info
Introduce a new option to record PERF_RECORD_NAMESPACES events emitted
by the kernel when fork, clone, setns or unshare are invoked. And update
perf-record documentation with the new option to record namespace
events.
Committer notes:
Combined it with a later patch to allow printing it via 'perf report -D'
and be able to test the feature introduced in this patch. Had to move
here also perf_ns__name(), that was introduced in another later patch.
Also used PRIu64 and PRIx64 to fix the build in some enfironments wrt:
util/event.c:1129:39: error: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type 'long long unsigned int' [-Werror=format=]
ret += fprintf(fp, "%u/%s: %lu/0x%lx%s", idx
^
Testing it:
# perf record --namespaces -a
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 1.083 MB perf.data (423 samples) ]
#
# perf report -D
<SNIP>
3 2028902078892 0x115140 [0xa0]: PERF_RECORD_NAMESPACES 14783/14783 - nr_namespaces: 7
[0/net: 3/0xf0000081, 1/uts: 3/0xeffffffe, 2/ipc: 3/0xefffffff, 3/pid: 3/0xeffffffc,
4/user: 3/0xeffffffd, 5/mnt: 3/0xf0000000, 6/cgroup: 3/0xeffffffb]
0x1151e0 [0x30]: event: 9
.
. ... raw event: size 48 bytes
. 0000: 09 00 00 00 02 00 30 00 c4 71 82 68 0c 7f 00 00 ......0..q.h....
. 0010: a9 39 00 00 a9 39 00 00 94 28 fe 63 d8 01 00 00 .9...9...(.c....
. 0020: 03 00 00 00 00 00 00 00 ce c4 02 00 00 00 00 00 ................
<SNIP>
NAMESPACES events: 1
<SNIP>
#
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sargun Dhillon <sargun@sargun.me>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/148891930386.25309.18412039920746995488.stgit@hbathini.in.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-03-07 20:41:43 +00:00
|
|
|
case PERF_RECORD_NAMESPACES:
|
|
|
|
return tool->namespaces(tool, event, sample, machine);
|
2020-03-25 12:45:30 +00:00
|
|
|
case PERF_RECORD_CGROUP:
|
|
|
|
return tool->cgroup(tool, event, sample, machine);
|
2010-12-05 13:32:55 +00:00
|
|
|
case PERF_RECORD_FORK:
|
2011-11-28 10:30:20 +00:00
|
|
|
return tool->fork(tool, event, sample, machine);
|
2010-12-05 13:32:55 +00:00
|
|
|
case PERF_RECORD_EXIT:
|
2011-11-28 10:30:20 +00:00
|
|
|
return tool->exit(tool, event, sample, machine);
|
2010-12-05 13:32:55 +00:00
|
|
|
case PERF_RECORD_LOST:
|
2011-11-28 10:30:20 +00:00
|
|
|
if (tool->lost == perf_event__process_lost)
|
2015-02-14 18:05:28 +00:00
|
|
|
evlist->stats.total_lost += event->lost.lost;
|
2011-11-28 10:30:20 +00:00
|
|
|
return tool->lost(tool, event, sample, machine);
|
2015-05-10 19:13:15 +00:00
|
|
|
case PERF_RECORD_LOST_SAMPLES:
|
|
|
|
if (tool->lost_samples == perf_event__process_lost_samples)
|
|
|
|
evlist->stats.total_lost_samples += event->lost_samples.lost;
|
|
|
|
return tool->lost_samples(tool, event, sample, machine);
|
2010-12-05 13:32:55 +00:00
|
|
|
case PERF_RECORD_READ:
|
2017-08-24 16:27:32 +00:00
|
|
|
dump_read(evsel, event);
|
2011-11-28 10:30:20 +00:00
|
|
|
return tool->read(tool, event, sample, evsel, machine);
|
2010-12-05 13:32:55 +00:00
|
|
|
case PERF_RECORD_THROTTLE:
|
2011-11-28 10:30:20 +00:00
|
|
|
return tool->throttle(tool, event, sample, machine);
|
2010-12-05 13:32:55 +00:00
|
|
|
case PERF_RECORD_UNTHROTTLE:
|
2011-11-28 10:30:20 +00:00
|
|
|
return tool->unthrottle(tool, event, sample, machine);
|
2015-04-30 14:37:29 +00:00
|
|
|
case PERF_RECORD_AUX:
|
2017-03-16 16:41:59 +00:00
|
|
|
if (tool->aux == perf_event__process_aux) {
|
|
|
|
if (event->aux.flags & PERF_AUX_FLAG_TRUNCATED)
|
|
|
|
evlist->stats.total_aux_lost += 1;
|
|
|
|
if (event->aux.flags & PERF_AUX_FLAG_PARTIAL)
|
|
|
|
evlist->stats.total_aux_partial += 1;
|
|
|
|
}
|
2015-04-30 14:37:29 +00:00
|
|
|
return tool->aux(tool, event, sample, machine);
|
2015-04-30 14:37:30 +00:00
|
|
|
case PERF_RECORD_ITRACE_START:
|
|
|
|
return tool->itrace_start(tool, event, sample, machine);
|
2015-07-21 09:44:03 +00:00
|
|
|
case PERF_RECORD_SWITCH:
|
|
|
|
case PERF_RECORD_SWITCH_CPU_WIDE:
|
|
|
|
return tool->context_switch(tool, event, sample, machine);
|
2019-01-17 16:15:17 +00:00
|
|
|
case PERF_RECORD_KSYMBOL:
|
|
|
|
return tool->ksymbol(tool, event, sample, machine);
|
perf tools: Handle PERF_RECORD_BPF_EVENT
This patch adds basic handling of PERF_RECORD_BPF_EVENT. Tracking of
PERF_RECORD_BPF_EVENT is OFF by default. Option --bpf-event is added to
turn it on.
Committer notes:
Add dummy machine__process_bpf_event() variant that returns zero for
systems without HAVE_LIBBPF_SUPPORT, such as Alpine Linux, unbreaking
the build in such systems.
Remove the needless include <machine.h> from bpf->event.h, provide just
forward declarations for the structs and unions in the parameters, to
reduce compilation time and needless rebuilds when machine.h gets
changed.
Committer testing:
When running with:
# perf record --bpf-event
On an older kernel where PERF_RECORD_BPF_EVENT and PERF_RECORD_KSYMBOL
is not present, we fallback to removing those two bits from
perf_event_attr, making the tool to continue to work on older kernels:
perf_event_attr:
size 112
{ sample_period, sample_freq } 4000
sample_type IP|TID|TIME|PERIOD
read_format ID
disabled 1
inherit 1
mmap 1
comm 1
freq 1
enable_on_exec 1
task 1
precise_ip 3
sample_id_all 1
exclude_guest 1
mmap2 1
comm_exec 1
ksymbol 1
bpf_event 1
------------------------------------------------------------
sys_perf_event_open: pid 5779 cpu 0 group_fd -1 flags 0x8
sys_perf_event_open failed, error -22
switching off bpf_event
------------------------------------------------------------
perf_event_attr:
size 112
{ sample_period, sample_freq } 4000
sample_type IP|TID|TIME|PERIOD
read_format ID
disabled 1
inherit 1
mmap 1
comm 1
freq 1
enable_on_exec 1
task 1
precise_ip 3
sample_id_all 1
exclude_guest 1
mmap2 1
comm_exec 1
ksymbol 1
------------------------------------------------------------
sys_perf_event_open: pid 5779 cpu 0 group_fd -1 flags 0x8
sys_perf_event_open failed, error -22
switching off ksymbol
------------------------------------------------------------
perf_event_attr:
size 112
{ sample_period, sample_freq } 4000
sample_type IP|TID|TIME|PERIOD
read_format ID
disabled 1
inherit 1
mmap 1
comm 1
freq 1
enable_on_exec 1
task 1
precise_ip 3
sample_id_all 1
exclude_guest 1
mmap2 1
comm_exec 1
------------------------------------------------------------
And then proceeds to work without those two features.
As passing --bpf-event is an explicit action performed by the user, perhaps we
should emit a warning telling that the kernel has no such feature, but this can
be done on top of this patch.
Now with a kernel that supports these events, start the 'record --bpf-event -a'
and then run 'perf trace sleep 10000' that will use the BPF
augmented_raw_syscalls.o prebuilt (for another kernel version even) and thus
should generate PERF_RECORD_BPF_EVENT events:
[root@quaco ~]# perf record -e dummy -a --bpf-event
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.713 MB perf.data ]
[root@quaco ~]# bpftool prog
13: cgroup_skb tag 7be49e3934a125ba gpl
loaded_at 2019-01-19T09:09:43-0300 uid 0
xlated 296B jited 229B memlock 4096B map_ids 13,14
14: cgroup_skb tag 2a142ef67aaad174 gpl
loaded_at 2019-01-19T09:09:43-0300 uid 0
xlated 296B jited 229B memlock 4096B map_ids 13,14
15: cgroup_skb tag 7be49e3934a125ba gpl
loaded_at 2019-01-19T09:09:43-0300 uid 0
xlated 296B jited 229B memlock 4096B map_ids 15,16
16: cgroup_skb tag 2a142ef67aaad174 gpl
loaded_at 2019-01-19T09:09:43-0300 uid 0
xlated 296B jited 229B memlock 4096B map_ids 15,16
17: cgroup_skb tag 7be49e3934a125ba gpl
loaded_at 2019-01-19T09:09:44-0300 uid 0
xlated 296B jited 229B memlock 4096B map_ids 17,18
18: cgroup_skb tag 2a142ef67aaad174 gpl
loaded_at 2019-01-19T09:09:44-0300 uid 0
xlated 296B jited 229B memlock 4096B map_ids 17,18
21: cgroup_skb tag 7be49e3934a125ba gpl
loaded_at 2019-01-19T09:09:45-0300 uid 0
xlated 296B jited 229B memlock 4096B map_ids 21,22
22: cgroup_skb tag 2a142ef67aaad174 gpl
loaded_at 2019-01-19T09:09:45-0300 uid 0
xlated 296B jited 229B memlock 4096B map_ids 21,22
31: tracepoint name sys_enter tag 12504ba9402f952f gpl
loaded_at 2019-01-19T09:19:56-0300 uid 0
xlated 512B jited 374B memlock 4096B map_ids 30,29,28
32: tracepoint name sys_exit tag c1bd85c092d6e4aa gpl
loaded_at 2019-01-19T09:19:56-0300 uid 0
xlated 256B jited 191B memlock 4096B map_ids 30,29
# perf report -D | grep PERF_RECORD_BPF_EVENT | nl
1 0 55834574849 0x4fc8 [0x18]: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 13
2 0 60129542145 0x5118 [0x18]: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 14
3 0 64424509441 0x5268 [0x18]: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 15
4 0 68719476737 0x53b8 [0x18]: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 16
5 0 73014444033 0x5508 [0x18]: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 17
6 0 77309411329 0x5658 [0x18]: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 18
7 0 90194313217 0x57a8 [0x18]: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 21
8 0 94489280513 0x58f8 [0x18]: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 22
9 7 620922484360 0xb6390 [0x30]: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 29
10 7 620922486018 0xb6410 [0x30]: PERF_RECORD_BPF_EVENT bpf event with type 2, flags 0, id 29
11 7 620922579199 0xb6490 [0x30]: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 30
12 7 620922580240 0xb6510 [0x30]: PERF_RECORD_BPF_EVENT bpf event with type 2, flags 0, id 30
13 7 620922765207 0xb6598 [0x30]: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 31
14 7 620922874543 0xb6620 [0x30]: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 32
#
There, the 31 and 32 tracepoint BPF programs put in place by 'perf trace'.
Signed-off-by: Song Liu <songliubraving@fb.com>
Reviewed-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: kernel-team@fb.com
Cc: netdev@vger.kernel.org
Link: http://lkml.kernel.org/r/20190117161521.1341602-7-songliubraving@fb.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-01-17 16:15:18 +00:00
|
|
|
case PERF_RECORD_BPF_EVENT:
|
2019-08-26 22:28:13 +00:00
|
|
|
return tool->bpf(tool, event, sample, machine);
|
2020-05-12 12:19:18 +00:00
|
|
|
case PERF_RECORD_TEXT_POKE:
|
|
|
|
return tool->text_poke(tool, event, sample, machine);
|
2010-12-05 13:32:55 +00:00
|
|
|
default:
|
2015-02-14 18:05:28 +00:00
|
|
|
++evlist->stats.nr_unknown_events;
|
2010-12-05 13:32:55 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-04-09 15:53:48 +00:00
|
|
|
static int perf_session__deliver_event(struct perf_session *session,
|
|
|
|
union perf_event *event,
|
|
|
|
struct perf_tool *tool,
|
|
|
|
u64 file_offset)
|
|
|
|
{
|
perf tools: Optimize sample parsing for ordered events
Currently when using ordered events we parse the sample twice (the
perf_evlist__parse_sample function). Once before we queue the sample for
sorting:
perf_session__process_event
perf_evlist__parse_sample(sample)
perf_session__queue_event(sample.time)
And then when we deliver the sorted sample:
ordered_events__deliver_event
perf_evlist__parse_sample
perf_session__deliver_event
We can skip the initial full sample parsing by using
perf_evlist__parse_sample_timestamp function, which got introduced
earlier. The new path looks like:
perf_session__process_event
perf_evlist__parse_sample_timestamp
perf_session__queue_event
ordered_events__deliver_event
perf_session__deliver_event
perf_evlist__parse_sample
It saves some instructions and is slightly faster:
Before:
Performance counter stats for './perf.old report --stdio' (5 runs):
64,396,007,225 cycles:u ( +- 0.97% )
105,882,112,735 instructions:u # 1.64 insn per cycle ( +- 0.00% )
21.618103465 seconds time elapsed ( +- 1.12% )
After:
Performance counter stats for './perf report --stdio' (5 runs):
60,567,807,182 cycles:u ( +- 0.40% )
104,853,333,514 instructions:u # 1.73 insn per cycle ( +- 0.00% )
20.168895243 seconds time elapsed ( +- 0.32% )
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-cjp2tuk0qkjs9dxzlpmm34ua@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-08-03 11:21:14 +00:00
|
|
|
struct perf_sample sample;
|
2020-11-30 12:43:07 +00:00
|
|
|
int ret = evlist__parse_sample(session->evlist, event, &sample);
|
2015-04-09 15:53:48 +00:00
|
|
|
|
perf tools: Optimize sample parsing for ordered events
Currently when using ordered events we parse the sample twice (the
perf_evlist__parse_sample function). Once before we queue the sample for
sorting:
perf_session__process_event
perf_evlist__parse_sample(sample)
perf_session__queue_event(sample.time)
And then when we deliver the sorted sample:
ordered_events__deliver_event
perf_evlist__parse_sample
perf_session__deliver_event
We can skip the initial full sample parsing by using
perf_evlist__parse_sample_timestamp function, which got introduced
earlier. The new path looks like:
perf_session__process_event
perf_evlist__parse_sample_timestamp
perf_session__queue_event
ordered_events__deliver_event
perf_session__deliver_event
perf_evlist__parse_sample
It saves some instructions and is slightly faster:
Before:
Performance counter stats for './perf.old report --stdio' (5 runs):
64,396,007,225 cycles:u ( +- 0.97% )
105,882,112,735 instructions:u # 1.64 insn per cycle ( +- 0.00% )
21.618103465 seconds time elapsed ( +- 1.12% )
After:
Performance counter stats for './perf report --stdio' (5 runs):
60,567,807,182 cycles:u ( +- 0.40% )
104,853,333,514 instructions:u # 1.73 insn per cycle ( +- 0.00% )
20.168895243 seconds time elapsed ( +- 0.32% )
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-cjp2tuk0qkjs9dxzlpmm34ua@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-08-03 11:21:14 +00:00
|
|
|
if (ret) {
|
|
|
|
pr_err("Can't parse sample, err = %d\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = auxtrace__process_event(session, event, &sample, tool);
|
2015-04-09 15:53:48 +00:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
if (ret > 0)
|
|
|
|
return 0;
|
|
|
|
|
2019-11-15 12:42:19 +00:00
|
|
|
ret = machines__deliver_event(&session->machines, session->evlist,
|
|
|
|
event, &sample, tool, file_offset);
|
|
|
|
|
|
|
|
if (dump_trace && sample.aux_sample.size)
|
|
|
|
auxtrace__dump_auxtrace_sample(session, &sample);
|
|
|
|
|
|
|
|
return ret;
|
2015-04-09 15:53:48 +00:00
|
|
|
}
|
|
|
|
|
2014-07-23 19:19:58 +00:00
|
|
|
static s64 perf_session__process_user_event(struct perf_session *session,
|
|
|
|
union perf_event *event,
|
|
|
|
u64 file_offset)
|
2009-12-27 23:36:59 +00:00
|
|
|
{
|
2015-03-03 15:37:54 +00:00
|
|
|
struct ordered_events *oe = &session->ordered_events;
|
2015-03-31 15:48:16 +00:00
|
|
|
struct perf_tool *tool = session->tool;
|
2017-11-23 18:35:04 +00:00
|
|
|
struct perf_sample sample = { .time = 0, };
|
2017-01-23 21:07:59 +00:00
|
|
|
int fd = perf_data__fd(session->data);
|
2011-11-12 00:45:41 +00:00
|
|
|
int err;
|
|
|
|
|
2019-03-18 17:45:11 +00:00
|
|
|
if (event->header.type != PERF_RECORD_COMPRESSED ||
|
|
|
|
tool->compressed == perf_session__process_compressed_event_stub)
|
|
|
|
dump_event(session->evlist, event, file_offset, &sample);
|
2009-12-27 23:36:59 +00:00
|
|
|
|
2010-12-05 13:32:55 +00:00
|
|
|
/* These events are processed right away */
|
2009-12-27 23:36:59 +00:00
|
|
|
switch (event->header.type) {
|
2010-04-02 04:59:19 +00:00
|
|
|
case PERF_RECORD_HEADER_ATTR:
|
2013-07-04 13:20:21 +00:00
|
|
|
err = tool->attr(tool, event, &session->evlist);
|
2014-07-31 06:00:45 +00:00
|
|
|
if (err == 0) {
|
2012-08-01 22:31:00 +00:00
|
|
|
perf_session__set_id_hdr_size(session);
|
2014-07-31 06:00:45 +00:00
|
|
|
perf_session__set_comm_exec(session);
|
|
|
|
}
|
2011-11-12 00:45:41 +00:00
|
|
|
return err;
|
2015-10-25 14:51:36 +00:00
|
|
|
case PERF_RECORD_EVENT_UPDATE:
|
|
|
|
return tool->event_update(tool, event, &session->evlist);
|
2014-02-04 14:37:48 +00:00
|
|
|
case PERF_RECORD_HEADER_EVENT_TYPE:
|
|
|
|
/*
|
|
|
|
* Depreceated, but we need to handle it for sake
|
|
|
|
* of old data files create in pipe mode.
|
|
|
|
*/
|
|
|
|
return 0;
|
2010-04-02 04:59:21 +00:00
|
|
|
case PERF_RECORD_HEADER_TRACING_DATA:
|
2020-05-07 09:50:21 +00:00
|
|
|
/*
|
|
|
|
* Setup for reading amidst mmap, but only when we
|
|
|
|
* are in 'file' mode. The 'pipe' fd is in proper
|
|
|
|
* place already.
|
|
|
|
*/
|
|
|
|
if (!perf_data__is_pipe(session->data))
|
|
|
|
lseek(fd, file_offset, SEEK_SET);
|
2018-09-13 12:54:03 +00:00
|
|
|
return tool->tracing_data(session, event);
|
2010-04-02 04:59:22 +00:00
|
|
|
case PERF_RECORD_HEADER_BUILD_ID:
|
2018-09-13 12:54:03 +00:00
|
|
|
return tool->build_id(session, event);
|
2010-05-03 13:14:33 +00:00
|
|
|
case PERF_RECORD_FINISHED_ROUND:
|
2015-03-03 15:37:54 +00:00
|
|
|
return tool->finished_round(tool, event, oe);
|
2014-10-27 13:49:22 +00:00
|
|
|
case PERF_RECORD_ID_INDEX:
|
2018-09-13 12:54:03 +00:00
|
|
|
return tool->id_index(session, event);
|
2015-04-09 15:53:43 +00:00
|
|
|
case PERF_RECORD_AUXTRACE_INFO:
|
2018-09-13 12:54:03 +00:00
|
|
|
return tool->auxtrace_info(session, event);
|
2015-04-09 15:53:43 +00:00
|
|
|
case PERF_RECORD_AUXTRACE:
|
|
|
|
/* setup for reading amidst mmap */
|
|
|
|
lseek(fd, file_offset + event->header.size, SEEK_SET);
|
2018-09-13 12:54:04 +00:00
|
|
|
return tool->auxtrace(session, event);
|
2015-04-09 15:53:47 +00:00
|
|
|
case PERF_RECORD_AUXTRACE_ERROR:
|
2015-04-09 15:53:50 +00:00
|
|
|
perf_session__auxtrace_error_inc(session, event);
|
2018-09-13 12:54:03 +00:00
|
|
|
return tool->auxtrace_error(session, event);
|
2015-10-25 14:51:19 +00:00
|
|
|
case PERF_RECORD_THREAD_MAP:
|
2018-09-13 12:54:03 +00:00
|
|
|
return tool->thread_map(session, event);
|
2015-10-25 14:51:23 +00:00
|
|
|
case PERF_RECORD_CPU_MAP:
|
2018-09-13 12:54:03 +00:00
|
|
|
return tool->cpu_map(session, event);
|
2015-10-25 14:51:27 +00:00
|
|
|
case PERF_RECORD_STAT_CONFIG:
|
2018-09-13 12:54:03 +00:00
|
|
|
return tool->stat_config(session, event);
|
2015-10-25 14:51:30 +00:00
|
|
|
case PERF_RECORD_STAT:
|
2018-09-13 12:54:03 +00:00
|
|
|
return tool->stat(session, event);
|
2015-10-25 14:51:33 +00:00
|
|
|
case PERF_RECORD_STAT_ROUND:
|
2018-09-13 12:54:03 +00:00
|
|
|
return tool->stat_round(session, event);
|
2016-03-08 08:38:44 +00:00
|
|
|
case PERF_RECORD_TIME_CONV:
|
|
|
|
session->time_conv = event->time_conv;
|
2018-09-13 12:54:03 +00:00
|
|
|
return tool->time_conv(session, event);
|
perf tools: Add feature header record to pipe-mode
Add header record types to pipe-mode, reusing the functions
used in file-mode and leveraging the new struct feat_fd.
For alignment, check that synthesized events don't exceed
pagesize.
Add the perf_event__synthesize_feature event call back to
process the new header records.
Before this patch:
$ perf record -o - -e cycles sleep 1 | perf report --stdio --header
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.000 MB - ]
...
After this patch:
$ perf record -o - -e cycles sleep 1 | perf report --stdio --header
# ========
# captured on: Mon May 22 16:33:43 2017
# ========
#
# hostname : my_hostname
# os release : 4.11.0-dbx-up_perf
# perf version : 4.11.rc6.g6277c80
# arch : x86_64
# nrcpus online : 72
# nrcpus avail : 72
# cpudesc : Intel(R) Xeon(R) CPU E5-2696 v3 @ 2.30GHz
# cpuid : GenuineIntel,6,63,2
# total memory : 263457192 kB
# cmdline : /root/perf record -o - -e cycles -c 100000 sleep 1
# HEADER_CPU_TOPOLOGY info available, use -I to display
# HEADER_NUMA_TOPOLOGY info available, use -I to display
# pmu mappings: intel_bts = 6, uncore_imc_4 = 22, uncore_sbox_1 = 47, uncore_cbox_5 = 33, uncore_ha_0 = 16, uncore_cbox
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.000 MB - ]
...
Support added for the subcommands: report, inject, annotate and script.
Signed-off-by: David Carrillo-Cisneros <davidcc@google.com>
Acked-by: David Ahern <dsahern@gmail.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Turner <pjt@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Simon Que <sque@chromium.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/20170718042549.145161-16-davidcc@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-07-18 04:25:48 +00:00
|
|
|
case PERF_RECORD_HEADER_FEATURE:
|
2018-09-13 12:54:03 +00:00
|
|
|
return tool->feature(session, event);
|
2019-03-18 17:45:11 +00:00
|
|
|
case PERF_RECORD_COMPRESSED:
|
|
|
|
err = tool->compressed(session, event, file_offset);
|
|
|
|
if (err)
|
|
|
|
dump_event(session->evlist, event, file_offset, &sample);
|
|
|
|
return err;
|
2009-12-27 23:36:59 +00:00
|
|
|
default:
|
2010-12-07 12:49:01 +00:00
|
|
|
return -EINVAL;
|
2009-12-27 23:36:59 +00:00
|
|
|
}
|
2010-12-07 12:49:01 +00:00
|
|
|
}
|
|
|
|
|
2014-10-27 13:49:23 +00:00
|
|
|
int perf_session__deliver_synth_event(struct perf_session *session,
|
|
|
|
union perf_event *event,
|
2015-03-03 14:58:45 +00:00
|
|
|
struct perf_sample *sample)
|
2014-10-27 13:49:23 +00:00
|
|
|
{
|
2019-07-21 11:23:52 +00:00
|
|
|
struct evlist *evlist = session->evlist;
|
2015-03-31 15:48:16 +00:00
|
|
|
struct perf_tool *tool = session->tool;
|
2015-03-03 14:48:12 +00:00
|
|
|
|
|
|
|
events_stats__inc(&evlist->stats, event->header.type);
|
2014-10-27 13:49:23 +00:00
|
|
|
|
|
|
|
if (event->header.type >= PERF_RECORD_USER_TYPE_START)
|
2015-03-03 14:58:45 +00:00
|
|
|
return perf_session__process_user_event(session, event, 0);
|
2014-10-27 13:49:23 +00:00
|
|
|
|
2015-03-03 14:48:12 +00:00
|
|
|
return machines__deliver_event(&session->machines, evlist, event, sample, tool, 0);
|
2014-10-27 13:49:23 +00:00
|
|
|
}
|
|
|
|
|
2012-05-30 12:23:43 +00:00
|
|
|
static void event_swap(union perf_event *event, bool sample_id_all)
|
|
|
|
{
|
|
|
|
perf_event__swap_op swap;
|
|
|
|
|
|
|
|
swap = perf_event__swap_ops[event->header.type];
|
|
|
|
if (swap)
|
|
|
|
swap(event, sample_id_all);
|
|
|
|
}
|
|
|
|
|
2014-07-31 06:00:57 +00:00
|
|
|
int perf_session__peek_event(struct perf_session *session, off_t file_offset,
|
|
|
|
void *buf, size_t buf_sz,
|
|
|
|
union perf_event **event_ptr,
|
|
|
|
struct perf_sample *sample)
|
|
|
|
{
|
|
|
|
union perf_event *event;
|
|
|
|
size_t hdr_sz, rest;
|
|
|
|
int fd;
|
|
|
|
|
|
|
|
if (session->one_mmap && !session->header.needs_swap) {
|
|
|
|
event = file_offset - session->one_mmap_offset +
|
|
|
|
session->one_mmap_addr;
|
|
|
|
goto out_parse_sample;
|
|
|
|
}
|
|
|
|
|
2017-01-23 21:07:59 +00:00
|
|
|
if (perf_data__is_pipe(session->data))
|
2014-07-31 06:00:57 +00:00
|
|
|
return -1;
|
|
|
|
|
2017-01-23 21:07:59 +00:00
|
|
|
fd = perf_data__fd(session->data);
|
2014-07-31 06:00:57 +00:00
|
|
|
hdr_sz = sizeof(struct perf_event_header);
|
|
|
|
|
|
|
|
if (buf_sz < hdr_sz)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
if (lseek(fd, file_offset, SEEK_SET) == (off_t)-1 ||
|
2015-05-19 13:05:45 +00:00
|
|
|
readn(fd, buf, hdr_sz) != (ssize_t)hdr_sz)
|
2014-07-31 06:00:57 +00:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
event = (union perf_event *)buf;
|
|
|
|
|
|
|
|
if (session->header.needs_swap)
|
|
|
|
perf_event_header__bswap(&event->header);
|
|
|
|
|
2015-05-19 13:05:45 +00:00
|
|
|
if (event->header.size < hdr_sz || event->header.size > buf_sz)
|
2014-07-31 06:00:57 +00:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
rest = event->header.size - hdr_sz;
|
|
|
|
|
2015-05-19 13:05:45 +00:00
|
|
|
if (readn(fd, buf, rest) != (ssize_t)rest)
|
2014-07-31 06:00:57 +00:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
if (session->header.needs_swap)
|
2020-06-17 12:29:48 +00:00
|
|
|
event_swap(event, evlist__sample_id_all(session->evlist));
|
2014-07-31 06:00:57 +00:00
|
|
|
|
|
|
|
out_parse_sample:
|
|
|
|
|
|
|
|
if (sample && event->header.type < PERF_RECORD_USER_TYPE_START &&
|
2020-11-30 12:43:07 +00:00
|
|
|
evlist__parse_sample(session->evlist, event, sample))
|
2014-07-31 06:00:57 +00:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
*event_ptr = event;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-11-15 12:42:20 +00:00
|
|
|
int perf_session__peek_events(struct perf_session *session, u64 offset,
|
|
|
|
u64 size, peek_events_cb_t cb, void *data)
|
|
|
|
{
|
|
|
|
u64 max_offset = offset + size;
|
|
|
|
char buf[PERF_SAMPLE_MAX_SIZE];
|
|
|
|
union perf_event *event;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
do {
|
|
|
|
err = perf_session__peek_event(session, offset, buf,
|
|
|
|
PERF_SAMPLE_MAX_SIZE, &event,
|
|
|
|
NULL);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
err = cb(session, event, offset, data);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
offset += event->header.size;
|
|
|
|
if (event->header.type == PERF_RECORD_AUXTRACE)
|
|
|
|
offset += event->auxtrace.size;
|
|
|
|
|
|
|
|
} while (offset < max_offset);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2014-07-23 19:19:58 +00:00
|
|
|
static s64 perf_session__process_event(struct perf_session *session,
|
2015-03-03 14:58:45 +00:00
|
|
|
union perf_event *event, u64 file_offset)
|
2010-12-07 12:49:01 +00:00
|
|
|
{
|
2019-07-21 11:23:52 +00:00
|
|
|
struct evlist *evlist = session->evlist;
|
2015-03-31 15:48:16 +00:00
|
|
|
struct perf_tool *tool = session->tool;
|
2010-12-07 12:49:01 +00:00
|
|
|
int ret;
|
|
|
|
|
2012-05-30 12:23:43 +00:00
|
|
|
if (session->header.needs_swap)
|
2020-06-17 12:29:48 +00:00
|
|
|
event_swap(event, evlist__sample_id_all(evlist));
|
2010-12-07 12:49:01 +00:00
|
|
|
|
|
|
|
if (event->header.type >= PERF_RECORD_HEADER_MAX)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2015-02-14 18:05:28 +00:00
|
|
|
events_stats__inc(&evlist->stats, event->header.type);
|
2010-12-07 12:49:01 +00:00
|
|
|
|
|
|
|
if (event->header.type >= PERF_RECORD_USER_TYPE_START)
|
2015-03-03 14:58:45 +00:00
|
|
|
return perf_session__process_user_event(session, event, file_offset);
|
2010-12-05 13:32:55 +00:00
|
|
|
|
2014-07-06 12:18:21 +00:00
|
|
|
if (tool->ordered_events) {
|
2018-01-10 20:31:52 +00:00
|
|
|
u64 timestamp = -1ULL;
|
perf tools: Optimize sample parsing for ordered events
Currently when using ordered events we parse the sample twice (the
perf_evlist__parse_sample function). Once before we queue the sample for
sorting:
perf_session__process_event
perf_evlist__parse_sample(sample)
perf_session__queue_event(sample.time)
And then when we deliver the sorted sample:
ordered_events__deliver_event
perf_evlist__parse_sample
perf_session__deliver_event
We can skip the initial full sample parsing by using
perf_evlist__parse_sample_timestamp function, which got introduced
earlier. The new path looks like:
perf_session__process_event
perf_evlist__parse_sample_timestamp
perf_session__queue_event
ordered_events__deliver_event
perf_session__deliver_event
perf_evlist__parse_sample
It saves some instructions and is slightly faster:
Before:
Performance counter stats for './perf.old report --stdio' (5 runs):
64,396,007,225 cycles:u ( +- 0.97% )
105,882,112,735 instructions:u # 1.64 insn per cycle ( +- 0.00% )
21.618103465 seconds time elapsed ( +- 1.12% )
After:
Performance counter stats for './perf report --stdio' (5 runs):
60,567,807,182 cycles:u ( +- 0.40% )
104,853,333,514 instructions:u # 1.73 insn per cycle ( +- 0.00% )
20.168895243 seconds time elapsed ( +- 0.32% )
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-cjp2tuk0qkjs9dxzlpmm34ua@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-08-03 11:21:14 +00:00
|
|
|
|
2020-11-30 12:43:07 +00:00
|
|
|
ret = evlist__parse_sample_timestamp(evlist, event, ×tamp);
|
2018-01-10 20:31:52 +00:00
|
|
|
if (ret && ret != -1)
|
perf tools: Optimize sample parsing for ordered events
Currently when using ordered events we parse the sample twice (the
perf_evlist__parse_sample function). Once before we queue the sample for
sorting:
perf_session__process_event
perf_evlist__parse_sample(sample)
perf_session__queue_event(sample.time)
And then when we deliver the sorted sample:
ordered_events__deliver_event
perf_evlist__parse_sample
perf_session__deliver_event
We can skip the initial full sample parsing by using
perf_evlist__parse_sample_timestamp function, which got introduced
earlier. The new path looks like:
perf_session__process_event
perf_evlist__parse_sample_timestamp
perf_session__queue_event
ordered_events__deliver_event
perf_session__deliver_event
perf_evlist__parse_sample
It saves some instructions and is slightly faster:
Before:
Performance counter stats for './perf.old report --stdio' (5 runs):
64,396,007,225 cycles:u ( +- 0.97% )
105,882,112,735 instructions:u # 1.64 insn per cycle ( +- 0.00% )
21.618103465 seconds time elapsed ( +- 1.12% )
After:
Performance counter stats for './perf report --stdio' (5 runs):
60,567,807,182 cycles:u ( +- 0.40% )
104,853,333,514 instructions:u # 1.73 insn per cycle ( +- 0.00% )
20.168895243 seconds time elapsed ( +- 0.32% )
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-cjp2tuk0qkjs9dxzlpmm34ua@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-08-03 11:21:14 +00:00
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = perf_session__queue_event(session, event, timestamp, file_offset);
|
2010-12-05 13:32:55 +00:00
|
|
|
if (ret != -ETIME)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
perf tools: Optimize sample parsing for ordered events
Currently when using ordered events we parse the sample twice (the
perf_evlist__parse_sample function). Once before we queue the sample for
sorting:
perf_session__process_event
perf_evlist__parse_sample(sample)
perf_session__queue_event(sample.time)
And then when we deliver the sorted sample:
ordered_events__deliver_event
perf_evlist__parse_sample
perf_session__deliver_event
We can skip the initial full sample parsing by using
perf_evlist__parse_sample_timestamp function, which got introduced
earlier. The new path looks like:
perf_session__process_event
perf_evlist__parse_sample_timestamp
perf_session__queue_event
ordered_events__deliver_event
perf_session__deliver_event
perf_evlist__parse_sample
It saves some instructions and is slightly faster:
Before:
Performance counter stats for './perf.old report --stdio' (5 runs):
64,396,007,225 cycles:u ( +- 0.97% )
105,882,112,735 instructions:u # 1.64 insn per cycle ( +- 0.00% )
21.618103465 seconds time elapsed ( +- 1.12% )
After:
Performance counter stats for './perf report --stdio' (5 runs):
60,567,807,182 cycles:u ( +- 0.40% )
104,853,333,514 instructions:u # 1.73 insn per cycle ( +- 0.00% )
20.168895243 seconds time elapsed ( +- 0.32% )
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-cjp2tuk0qkjs9dxzlpmm34ua@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-08-03 11:21:14 +00:00
|
|
|
return perf_session__deliver_event(session, event, tool, file_offset);
|
2009-12-27 23:36:59 +00:00
|
|
|
}
|
|
|
|
|
2013-11-05 18:32:36 +00:00
|
|
|
void perf_event_header__bswap(struct perf_event_header *hdr)
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
{
|
2013-11-05 18:32:36 +00:00
|
|
|
hdr->type = bswap_32(hdr->type);
|
|
|
|
hdr->misc = bswap_16(hdr->misc);
|
|
|
|
hdr->size = bswap_16(hdr->size);
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
}
|
|
|
|
|
2011-11-09 15:24:25 +00:00
|
|
|
struct thread *perf_session__findnew(struct perf_session *session, pid_t pid)
|
|
|
|
{
|
2014-07-14 10:02:25 +00:00
|
|
|
return machine__findnew_thread(&session->machines.host, -1, pid);
|
2011-11-09 15:24:25 +00:00
|
|
|
}
|
|
|
|
|
2015-12-09 02:11:23 +00:00
|
|
|
int perf_session__register_idle_thread(struct perf_session *session)
|
2009-12-27 23:36:59 +00:00
|
|
|
{
|
2021-02-18 09:57:56 +00:00
|
|
|
struct thread *thread = machine__idle_thread(&session->machines.host);
|
2009-12-27 23:36:59 +00:00
|
|
|
|
2021-02-18 09:57:56 +00:00
|
|
|
/* machine__idle_thread() got the thread, so put it */
|
2015-12-09 02:11:23 +00:00
|
|
|
thread__put(thread);
|
2021-02-18 09:57:56 +00:00
|
|
|
return thread ? 0 : -1;
|
2009-12-27 23:36:59 +00:00
|
|
|
}
|
|
|
|
|
2016-07-14 08:34:46 +00:00
|
|
|
static void
|
|
|
|
perf_session__warn_order(const struct perf_session *session)
|
|
|
|
{
|
|
|
|
const struct ordered_events *oe = &session->ordered_events;
|
2019-07-21 11:23:51 +00:00
|
|
|
struct evsel *evsel;
|
2016-07-14 08:34:46 +00:00
|
|
|
bool should_warn = true;
|
|
|
|
|
|
|
|
evlist__for_each_entry(session->evlist, evsel) {
|
2019-07-21 11:24:29 +00:00
|
|
|
if (evsel->core.attr.write_backward)
|
2016-07-14 08:34:46 +00:00
|
|
|
should_warn = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!should_warn)
|
|
|
|
return;
|
|
|
|
if (oe->nr_unordered_events != 0)
|
|
|
|
ui__warning("%u out of order events recorded.\n", oe->nr_unordered_events);
|
|
|
|
}
|
|
|
|
|
2015-03-31 15:48:16 +00:00
|
|
|
static void perf_session__warn_about_errors(const struct perf_session *session)
|
2011-01-04 18:25:15 +00:00
|
|
|
{
|
2015-03-31 15:48:16 +00:00
|
|
|
const struct events_stats *stats = &session->evlist->stats;
|
|
|
|
|
|
|
|
if (session->tool->lost == perf_event__process_lost &&
|
2015-02-14 17:57:13 +00:00
|
|
|
stats->nr_events[PERF_RECORD_LOST] != 0) {
|
2011-10-29 14:15:04 +00:00
|
|
|
ui__warning("Processed %d events and lost %d chunks!\n\n"
|
|
|
|
"Check IO/CPU overload!\n\n",
|
2015-02-14 17:57:13 +00:00
|
|
|
stats->nr_events[0],
|
|
|
|
stats->nr_events[PERF_RECORD_LOST]);
|
2011-01-04 18:25:15 +00:00
|
|
|
}
|
|
|
|
|
2015-05-10 19:13:15 +00:00
|
|
|
if (session->tool->lost_samples == perf_event__process_lost_samples) {
|
|
|
|
double drop_rate;
|
|
|
|
|
|
|
|
drop_rate = (double)stats->total_lost_samples /
|
|
|
|
(double) (stats->nr_events[PERF_RECORD_SAMPLE] + stats->total_lost_samples);
|
|
|
|
if (drop_rate > 0.05) {
|
2018-04-05 17:34:09 +00:00
|
|
|
ui__warning("Processed %" PRIu64 " samples and lost %3.2f%%!\n\n",
|
2015-05-10 19:13:15 +00:00
|
|
|
stats->nr_events[PERF_RECORD_SAMPLE] + stats->total_lost_samples,
|
|
|
|
drop_rate * 100.0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-25 13:15:37 +00:00
|
|
|
if (session->tool->aux == perf_event__process_aux &&
|
|
|
|
stats->total_aux_lost != 0) {
|
|
|
|
ui__warning("AUX data lost %" PRIu64 " times out of %u!\n\n",
|
|
|
|
stats->total_aux_lost,
|
|
|
|
stats->nr_events[PERF_RECORD_AUX]);
|
|
|
|
}
|
|
|
|
|
2017-03-16 16:41:59 +00:00
|
|
|
if (session->tool->aux == perf_event__process_aux &&
|
|
|
|
stats->total_aux_partial != 0) {
|
|
|
|
bool vmm_exclusive = false;
|
|
|
|
|
|
|
|
(void)sysfs__read_bool("module/kvm_intel/parameters/vmm_exclusive",
|
|
|
|
&vmm_exclusive);
|
|
|
|
|
|
|
|
ui__warning("AUX data had gaps in it %" PRIu64 " times out of %u!\n\n"
|
|
|
|
"Are you running a KVM guest in the background?%s\n\n",
|
|
|
|
stats->total_aux_partial,
|
|
|
|
stats->nr_events[PERF_RECORD_AUX],
|
|
|
|
vmm_exclusive ?
|
|
|
|
"\nReloading kvm_intel module with vmm_exclusive=0\n"
|
|
|
|
"will reduce the gaps to only guest's timeslices." :
|
|
|
|
"");
|
|
|
|
}
|
|
|
|
|
2015-02-14 17:57:13 +00:00
|
|
|
if (stats->nr_unknown_events != 0) {
|
2011-01-04 18:25:15 +00:00
|
|
|
ui__warning("Found %u unknown events!\n\n"
|
|
|
|
"Is this an older tool processing a perf.data "
|
|
|
|
"file generated by a more recent tool?\n\n"
|
|
|
|
"If that is not the case, consider "
|
|
|
|
"reporting to linux-kernel@vger.kernel.org.\n\n",
|
2015-02-14 17:57:13 +00:00
|
|
|
stats->nr_unknown_events);
|
2011-01-04 18:25:15 +00:00
|
|
|
}
|
|
|
|
|
2015-02-14 17:57:13 +00:00
|
|
|
if (stats->nr_unknown_id != 0) {
|
2011-03-15 18:44:01 +00:00
|
|
|
ui__warning("%u samples with id not present in the header\n",
|
2015-02-14 17:57:13 +00:00
|
|
|
stats->nr_unknown_id);
|
2011-03-15 18:44:01 +00:00
|
|
|
}
|
|
|
|
|
2015-02-14 17:57:13 +00:00
|
|
|
if (stats->nr_invalid_chains != 0) {
|
2015-02-14 17:50:11 +00:00
|
|
|
ui__warning("Found invalid callchains!\n\n"
|
|
|
|
"%u out of %u events were discarded for this reason.\n\n"
|
|
|
|
"Consider reporting to linux-kernel@vger.kernel.org.\n\n",
|
2015-02-14 17:57:13 +00:00
|
|
|
stats->nr_invalid_chains,
|
|
|
|
stats->nr_events[PERF_RECORD_SAMPLE]);
|
2015-02-14 17:50:11 +00:00
|
|
|
}
|
2012-02-10 17:05:04 +00:00
|
|
|
|
2015-02-14 17:57:13 +00:00
|
|
|
if (stats->nr_unprocessable_samples != 0) {
|
2012-02-10 17:05:04 +00:00
|
|
|
ui__warning("%u unprocessable samples recorded.\n"
|
|
|
|
"Do you have a KVM guest running and not using 'perf kvm'?\n",
|
2015-02-14 17:57:13 +00:00
|
|
|
stats->nr_unprocessable_samples);
|
2012-02-10 17:05:04 +00:00
|
|
|
}
|
2014-11-26 15:39:31 +00:00
|
|
|
|
2016-07-14 08:34:46 +00:00
|
|
|
perf_session__warn_order(session);
|
2015-04-09 15:53:50 +00:00
|
|
|
|
|
|
|
events_stats__auxtrace_error_warn(stats);
|
2015-06-17 13:51:10 +00:00
|
|
|
|
|
|
|
if (stats->nr_proc_map_timeout != 0) {
|
|
|
|
ui__warning("%d map information files for pre-existing threads were\n"
|
|
|
|
"not processed, if there are samples for addresses they\n"
|
|
|
|
"will not be resolved, you may find out which are these\n"
|
|
|
|
"threads by running with -v and redirecting the output\n"
|
2015-06-17 13:51:11 +00:00
|
|
|
"to a file.\n"
|
|
|
|
"The time limit to process proc map is too short?\n"
|
|
|
|
"Increase it by --proc-map-timeout\n",
|
2015-06-17 13:51:10 +00:00
|
|
|
stats->nr_proc_map_timeout);
|
|
|
|
}
|
2011-01-04 18:25:15 +00:00
|
|
|
}
|
|
|
|
|
2015-05-29 13:33:30 +00:00
|
|
|
static int perf_session__flush_thread_stack(struct thread *thread,
|
|
|
|
void *p __maybe_unused)
|
|
|
|
{
|
|
|
|
return thread_stack__flush(thread);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int perf_session__flush_thread_stacks(struct perf_session *session)
|
|
|
|
{
|
|
|
|
return machines__for_each_thread(&session->machines,
|
|
|
|
perf_session__flush_thread_stack,
|
|
|
|
NULL);
|
|
|
|
}
|
|
|
|
|
2010-04-02 04:59:15 +00:00
|
|
|
volatile int session_done;
|
|
|
|
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
static int __perf_session__process_decomp_events(struct perf_session *session);
|
|
|
|
|
2015-03-03 14:58:45 +00:00
|
|
|
static int __perf_session__process_pipe_events(struct perf_session *session)
|
2010-04-02 04:59:15 +00:00
|
|
|
{
|
2015-03-03 14:48:12 +00:00
|
|
|
struct ordered_events *oe = &session->ordered_events;
|
2015-03-31 15:48:16 +00:00
|
|
|
struct perf_tool *tool = session->tool;
|
perf tools: Fix piped mode read code
In __perf_session__process_pipe_events(), there was a risk we would read
more than what a union perf_event struct can hold. this could happen in
case, perf is reading a file which contains new record types it does not
know about and which are larger than anything it knows about.
In general, perf is supposed to skip records it does not understand, but
in pipe mode, those have to be read and ignored. The fixed size header
contains the size of the record, but that size may be larger than union
perf_event, yet it was used as the backing to the read in:
union perf_event event;
void *p;
size = event->header.size;
p = &event;
p += sizeof(struct perf_event_header);
if (size - sizeof(struct perf_event_header)) {
err = readn(self->fd, p, size - sizeof(struct perf_event_header));
We fix this by allocating a buffer based on the size reported in the
header. We reuse the buffer as much as we can. We realloc in case it
becomes too small. In the common case, the performance impact is
negligible.
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1337081295-10303-3-git-send-email-eranian@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2012-05-15 11:28:12 +00:00
|
|
|
union perf_event *event;
|
|
|
|
uint32_t size, cur_size = 0;
|
|
|
|
void *buf = NULL;
|
2014-07-23 19:19:58 +00:00
|
|
|
s64 skip = 0;
|
2010-04-02 04:59:15 +00:00
|
|
|
u64 head;
|
2013-11-28 10:30:14 +00:00
|
|
|
ssize_t err;
|
2010-04-02 04:59:15 +00:00
|
|
|
void *p;
|
|
|
|
|
2011-11-28 10:30:20 +00:00
|
|
|
perf_tool__fill_defaults(tool);
|
2010-04-02 04:59:15 +00:00
|
|
|
|
|
|
|
head = 0;
|
perf tools: Fix piped mode read code
In __perf_session__process_pipe_events(), there was a risk we would read
more than what a union perf_event struct can hold. this could happen in
case, perf is reading a file which contains new record types it does not
know about and which are larger than anything it knows about.
In general, perf is supposed to skip records it does not understand, but
in pipe mode, those have to be read and ignored. The fixed size header
contains the size of the record, but that size may be larger than union
perf_event, yet it was used as the backing to the read in:
union perf_event event;
void *p;
size = event->header.size;
p = &event;
p += sizeof(struct perf_event_header);
if (size - sizeof(struct perf_event_header)) {
err = readn(self->fd, p, size - sizeof(struct perf_event_header));
We fix this by allocating a buffer based on the size reported in the
header. We reuse the buffer as much as we can. We realloc in case it
becomes too small. In the common case, the performance impact is
negligible.
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1337081295-10303-3-git-send-email-eranian@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2012-05-15 11:28:12 +00:00
|
|
|
cur_size = sizeof(union perf_event);
|
|
|
|
|
|
|
|
buf = malloc(cur_size);
|
|
|
|
if (!buf)
|
|
|
|
return -errno;
|
perf inject: Copy events when reordering events in pipe mode
__perf_session__process_pipe_events reuses the same memory buffer to
process all events in the pipe.
When reordering is needed (e.g. -b option), events are not immediately
flushed, but kept around until reordering is possible, causing
memory corruption.
The problem is usually observed by a "Unknown sample error" output. It
can easily be reproduced by:
perf record -o - noploop | perf inject -b > output
Committer testing:
Before:
$ perf record -o - stress -t 2 -c 2 | perf inject -b > /dev/null
stress: info: [8297] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd
stress: info: [8297] successful run completed in 2s
[ perf record: Woken up 3 times to write data ]
[ perf record: Captured and wrote 0.000 MB - ]
Warning:
Found 1 unknown events!
Is this an older tool processing a perf.data file generated by a more recent tool?
If that is not the case, consider reporting to linux-kernel@vger.kernel.org.
$
After:
$ perf record -o - stress -t 2 -c 2 | perf inject -b > /dev/null
stress: info: [9027] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd
stress: info: [9027] successful run completed in 2s
[ perf record: Woken up 3 times to write data ]
[ perf record: Captured and wrote 0.000 MB - ]
no symbols found in /usr/bin/stress, maybe install a debug package?
no symbols found in /usr/bin/stress, maybe install a debug package?
$
Signed-off-by: David Carrillo-Cisneros <davidcc@google.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Paul Turner <pjt@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Simon Que <sque@chromium.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/20170410201432.24807-3-davidcc@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-04-10 20:14:27 +00:00
|
|
|
ordered_events__set_copy_on_queue(oe, true);
|
2010-04-02 04:59:15 +00:00
|
|
|
more:
|
perf tools: Fix piped mode read code
In __perf_session__process_pipe_events(), there was a risk we would read
more than what a union perf_event struct can hold. this could happen in
case, perf is reading a file which contains new record types it does not
know about and which are larger than anything it knows about.
In general, perf is supposed to skip records it does not understand, but
in pipe mode, those have to be read and ignored. The fixed size header
contains the size of the record, but that size may be larger than union
perf_event, yet it was used as the backing to the read in:
union perf_event event;
void *p;
size = event->header.size;
p = &event;
p += sizeof(struct perf_event_header);
if (size - sizeof(struct perf_event_header)) {
err = readn(self->fd, p, size - sizeof(struct perf_event_header));
We fix this by allocating a buffer based on the size reported in the
header. We reuse the buffer as much as we can. We realloc in case it
becomes too small. In the common case, the performance impact is
negligible.
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1337081295-10303-3-git-send-email-eranian@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2012-05-15 11:28:12 +00:00
|
|
|
event = buf;
|
perf data: Allow to use stdio functions for pipe mode
When perf data is in a pipe, it reads each event separately using
read(2) syscall. This is a huge performance bottleneck when
processing large data like in perf inject. Also perf inject needs to
use write(2) syscall for the output.
So convert it to use buffer I/O functions in stdio library for pipe
data. This makes inject-build-id bench time drops from 20ms to 8ms.
$ perf bench internals inject-build-id
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 8.074 msec (+- 0.013 msec)
Average time per event: 0.792 usec (+- 0.001 usec)
Average memory usage: 8328 KB (+- 0 KB)
Average build-id-all injection took: 5.490 msec (+- 0.008 msec)
Average time per event: 0.538 usec (+- 0.001 usec)
Average memory usage: 7563 KB (+- 0 KB)
This patch enables it just for perf inject when used with pipe (it's a
default behavior). Maybe we could do it for perf record and/or report
later..
Committer testing:
Before:
$ perf stat -r 5 perf bench internals inject-build-id
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 13.605 msec (+- 0.064 msec)
Average time per event: 1.334 usec (+- 0.006 usec)
Average memory usage: 12220 KB (+- 7 KB)
Average build-id-all injection took: 11.458 msec (+- 0.058 msec)
Average time per event: 1.123 usec (+- 0.006 usec)
Average memory usage: 11546 KB (+- 8 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 13.673 msec (+- 0.057 msec)
Average time per event: 1.341 usec (+- 0.006 usec)
Average memory usage: 12508 KB (+- 8 KB)
Average build-id-all injection took: 11.437 msec (+- 0.046 msec)
Average time per event: 1.121 usec (+- 0.004 usec)
Average memory usage: 11812 KB (+- 7 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 13.641 msec (+- 0.069 msec)
Average time per event: 1.337 usec (+- 0.007 usec)
Average memory usage: 12302 KB (+- 8 KB)
Average build-id-all injection took: 10.820 msec (+- 0.106 msec)
Average time per event: 1.061 usec (+- 0.010 usec)
Average memory usage: 11616 KB (+- 7 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 13.379 msec (+- 0.074 msec)
Average time per event: 1.312 usec (+- 0.007 usec)
Average memory usage: 12334 KB (+- 8 KB)
Average build-id-all injection took: 11.288 msec (+- 0.071 msec)
Average time per event: 1.107 usec (+- 0.007 usec)
Average memory usage: 11657 KB (+- 8 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 13.534 msec (+- 0.058 msec)
Average time per event: 1.327 usec (+- 0.006 usec)
Average memory usage: 12264 KB (+- 8 KB)
Average build-id-all injection took: 11.557 msec (+- 0.076 msec)
Average time per event: 1.133 usec (+- 0.007 usec)
Average memory usage: 11593 KB (+- 8 KB)
Performance counter stats for 'perf bench internals inject-build-id' (5 runs):
4,060.05 msec task-clock:u # 1.566 CPUs utilized ( +- 0.65% )
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
101,888 page-faults:u # 0.025 M/sec ( +- 0.12% )
3,745,833,163 cycles:u # 0.923 GHz ( +- 0.10% ) (83.22%)
194,346,613 stalled-cycles-frontend:u # 5.19% frontend cycles idle ( +- 0.57% ) (83.30%)
708,495,034 stalled-cycles-backend:u # 18.91% backend cycles idle ( +- 0.48% ) (83.48%)
5,629,328,628 instructions:u # 1.50 insn per cycle
# 0.13 stalled cycles per insn ( +- 0.21% ) (83.57%)
1,236,697,927 branches:u # 304.602 M/sec ( +- 0.16% ) (83.44%)
17,564,877 branch-misses:u # 1.42% of all branches ( +- 0.23% ) (82.99%)
2.5934 +- 0.0128 seconds time elapsed ( +- 0.49% )
$
After:
$ perf stat -r 5 perf bench internals inject-build-id
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 8.560 msec (+- 0.125 msec)
Average time per event: 0.839 usec (+- 0.012 usec)
Average memory usage: 12520 KB (+- 8 KB)
Average build-id-all injection took: 5.789 msec (+- 0.054 msec)
Average time per event: 0.568 usec (+- 0.005 usec)
Average memory usage: 11919 KB (+- 9 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 8.639 msec (+- 0.111 msec)
Average time per event: 0.847 usec (+- 0.011 usec)
Average memory usage: 12732 KB (+- 8 KB)
Average build-id-all injection took: 5.647 msec (+- 0.069 msec)
Average time per event: 0.554 usec (+- 0.007 usec)
Average memory usage: 12093 KB (+- 7 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 8.551 msec (+- 0.096 msec)
Average time per event: 0.838 usec (+- 0.009 usec)
Average memory usage: 12739 KB (+- 8 KB)
Average build-id-all injection took: 5.617 msec (+- 0.061 msec)
Average time per event: 0.551 usec (+- 0.006 usec)
Average memory usage: 12105 KB (+- 7 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 8.403 msec (+- 0.097 msec)
Average time per event: 0.824 usec (+- 0.010 usec)
Average memory usage: 12770 KB (+- 8 KB)
Average build-id-all injection took: 5.611 msec (+- 0.085 msec)
Average time per event: 0.550 usec (+- 0.008 usec)
Average memory usage: 12134 KB (+- 8 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 8.518 msec (+- 0.102 msec)
Average time per event: 0.835 usec (+- 0.010 usec)
Average memory usage: 12518 KB (+- 10 KB)
Average build-id-all injection took: 5.503 msec (+- 0.073 msec)
Average time per event: 0.540 usec (+- 0.007 usec)
Average memory usage: 11882 KB (+- 8 KB)
Performance counter stats for 'perf bench internals inject-build-id' (5 runs):
2,394.88 msec task-clock:u # 1.577 CPUs utilized ( +- 0.83% )
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
103,181 page-faults:u # 0.043 M/sec ( +- 0.11% )
3,548,172,030 cycles:u # 1.482 GHz ( +- 0.30% ) (83.26%)
81,537,700 stalled-cycles-frontend:u # 2.30% frontend cycles idle ( +- 1.54% ) (83.24%)
876,631,544 stalled-cycles-backend:u # 24.71% backend cycles idle ( +- 1.14% ) (83.45%)
5,960,361,707 instructions:u # 1.68 insn per cycle
# 0.15 stalled cycles per insn ( +- 0.27% ) (83.26%)
1,269,413,491 branches:u # 530.054 M/sec ( +- 0.10% ) (83.48%)
11,372,453 branch-misses:u # 0.90% of all branches ( +- 0.52% ) (83.31%)
1.51874 +- 0.00642 seconds time elapsed ( +- 0.42% )
$
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lore.kernel.org/lkml/20201030054742.87740-1-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-10-30 05:47:42 +00:00
|
|
|
err = perf_data__read(session->data, event,
|
|
|
|
sizeof(struct perf_event_header));
|
2010-04-02 04:59:15 +00:00
|
|
|
if (err <= 0) {
|
|
|
|
if (err == 0)
|
|
|
|
goto done;
|
|
|
|
|
|
|
|
pr_err("failed to read event header\n");
|
|
|
|
goto out_err;
|
|
|
|
}
|
|
|
|
|
2013-11-05 18:32:36 +00:00
|
|
|
if (session->header.needs_swap)
|
perf tools: Fix piped mode read code
In __perf_session__process_pipe_events(), there was a risk we would read
more than what a union perf_event struct can hold. this could happen in
case, perf is reading a file which contains new record types it does not
know about and which are larger than anything it knows about.
In general, perf is supposed to skip records it does not understand, but
in pipe mode, those have to be read and ignored. The fixed size header
contains the size of the record, but that size may be larger than union
perf_event, yet it was used as the backing to the read in:
union perf_event event;
void *p;
size = event->header.size;
p = &event;
p += sizeof(struct perf_event_header);
if (size - sizeof(struct perf_event_header)) {
err = readn(self->fd, p, size - sizeof(struct perf_event_header));
We fix this by allocating a buffer based on the size reported in the
header. We reuse the buffer as much as we can. We realloc in case it
becomes too small. In the common case, the performance impact is
negligible.
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1337081295-10303-3-git-send-email-eranian@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2012-05-15 11:28:12 +00:00
|
|
|
perf_event_header__bswap(&event->header);
|
2010-04-02 04:59:15 +00:00
|
|
|
|
perf tools: Fix piped mode read code
In __perf_session__process_pipe_events(), there was a risk we would read
more than what a union perf_event struct can hold. this could happen in
case, perf is reading a file which contains new record types it does not
know about and which are larger than anything it knows about.
In general, perf is supposed to skip records it does not understand, but
in pipe mode, those have to be read and ignored. The fixed size header
contains the size of the record, but that size may be larger than union
perf_event, yet it was used as the backing to the read in:
union perf_event event;
void *p;
size = event->header.size;
p = &event;
p += sizeof(struct perf_event_header);
if (size - sizeof(struct perf_event_header)) {
err = readn(self->fd, p, size - sizeof(struct perf_event_header));
We fix this by allocating a buffer based on the size reported in the
header. We reuse the buffer as much as we can. We realloc in case it
becomes too small. In the common case, the performance impact is
negligible.
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1337081295-10303-3-git-send-email-eranian@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2012-05-15 11:28:12 +00:00
|
|
|
size = event->header.size;
|
2013-07-04 13:20:27 +00:00
|
|
|
if (size < sizeof(struct perf_event_header)) {
|
|
|
|
pr_err("bad event header size\n");
|
|
|
|
goto out_err;
|
|
|
|
}
|
2010-04-02 04:59:15 +00:00
|
|
|
|
perf tools: Fix piped mode read code
In __perf_session__process_pipe_events(), there was a risk we would read
more than what a union perf_event struct can hold. this could happen in
case, perf is reading a file which contains new record types it does not
know about and which are larger than anything it knows about.
In general, perf is supposed to skip records it does not understand, but
in pipe mode, those have to be read and ignored. The fixed size header
contains the size of the record, but that size may be larger than union
perf_event, yet it was used as the backing to the read in:
union perf_event event;
void *p;
size = event->header.size;
p = &event;
p += sizeof(struct perf_event_header);
if (size - sizeof(struct perf_event_header)) {
err = readn(self->fd, p, size - sizeof(struct perf_event_header));
We fix this by allocating a buffer based on the size reported in the
header. We reuse the buffer as much as we can. We realloc in case it
becomes too small. In the common case, the performance impact is
negligible.
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1337081295-10303-3-git-send-email-eranian@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2012-05-15 11:28:12 +00:00
|
|
|
if (size > cur_size) {
|
|
|
|
void *new = realloc(buf, size);
|
|
|
|
if (!new) {
|
|
|
|
pr_err("failed to allocate memory to read event\n");
|
|
|
|
goto out_err;
|
|
|
|
}
|
|
|
|
buf = new;
|
|
|
|
cur_size = size;
|
|
|
|
event = buf;
|
|
|
|
}
|
|
|
|
p = event;
|
2010-04-02 04:59:15 +00:00
|
|
|
p += sizeof(struct perf_event_header);
|
|
|
|
|
2010-05-05 05:27:40 +00:00
|
|
|
if (size - sizeof(struct perf_event_header)) {
|
perf data: Allow to use stdio functions for pipe mode
When perf data is in a pipe, it reads each event separately using
read(2) syscall. This is a huge performance bottleneck when
processing large data like in perf inject. Also perf inject needs to
use write(2) syscall for the output.
So convert it to use buffer I/O functions in stdio library for pipe
data. This makes inject-build-id bench time drops from 20ms to 8ms.
$ perf bench internals inject-build-id
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 8.074 msec (+- 0.013 msec)
Average time per event: 0.792 usec (+- 0.001 usec)
Average memory usage: 8328 KB (+- 0 KB)
Average build-id-all injection took: 5.490 msec (+- 0.008 msec)
Average time per event: 0.538 usec (+- 0.001 usec)
Average memory usage: 7563 KB (+- 0 KB)
This patch enables it just for perf inject when used with pipe (it's a
default behavior). Maybe we could do it for perf record and/or report
later..
Committer testing:
Before:
$ perf stat -r 5 perf bench internals inject-build-id
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 13.605 msec (+- 0.064 msec)
Average time per event: 1.334 usec (+- 0.006 usec)
Average memory usage: 12220 KB (+- 7 KB)
Average build-id-all injection took: 11.458 msec (+- 0.058 msec)
Average time per event: 1.123 usec (+- 0.006 usec)
Average memory usage: 11546 KB (+- 8 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 13.673 msec (+- 0.057 msec)
Average time per event: 1.341 usec (+- 0.006 usec)
Average memory usage: 12508 KB (+- 8 KB)
Average build-id-all injection took: 11.437 msec (+- 0.046 msec)
Average time per event: 1.121 usec (+- 0.004 usec)
Average memory usage: 11812 KB (+- 7 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 13.641 msec (+- 0.069 msec)
Average time per event: 1.337 usec (+- 0.007 usec)
Average memory usage: 12302 KB (+- 8 KB)
Average build-id-all injection took: 10.820 msec (+- 0.106 msec)
Average time per event: 1.061 usec (+- 0.010 usec)
Average memory usage: 11616 KB (+- 7 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 13.379 msec (+- 0.074 msec)
Average time per event: 1.312 usec (+- 0.007 usec)
Average memory usage: 12334 KB (+- 8 KB)
Average build-id-all injection took: 11.288 msec (+- 0.071 msec)
Average time per event: 1.107 usec (+- 0.007 usec)
Average memory usage: 11657 KB (+- 8 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 13.534 msec (+- 0.058 msec)
Average time per event: 1.327 usec (+- 0.006 usec)
Average memory usage: 12264 KB (+- 8 KB)
Average build-id-all injection took: 11.557 msec (+- 0.076 msec)
Average time per event: 1.133 usec (+- 0.007 usec)
Average memory usage: 11593 KB (+- 8 KB)
Performance counter stats for 'perf bench internals inject-build-id' (5 runs):
4,060.05 msec task-clock:u # 1.566 CPUs utilized ( +- 0.65% )
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
101,888 page-faults:u # 0.025 M/sec ( +- 0.12% )
3,745,833,163 cycles:u # 0.923 GHz ( +- 0.10% ) (83.22%)
194,346,613 stalled-cycles-frontend:u # 5.19% frontend cycles idle ( +- 0.57% ) (83.30%)
708,495,034 stalled-cycles-backend:u # 18.91% backend cycles idle ( +- 0.48% ) (83.48%)
5,629,328,628 instructions:u # 1.50 insn per cycle
# 0.13 stalled cycles per insn ( +- 0.21% ) (83.57%)
1,236,697,927 branches:u # 304.602 M/sec ( +- 0.16% ) (83.44%)
17,564,877 branch-misses:u # 1.42% of all branches ( +- 0.23% ) (82.99%)
2.5934 +- 0.0128 seconds time elapsed ( +- 0.49% )
$
After:
$ perf stat -r 5 perf bench internals inject-build-id
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 8.560 msec (+- 0.125 msec)
Average time per event: 0.839 usec (+- 0.012 usec)
Average memory usage: 12520 KB (+- 8 KB)
Average build-id-all injection took: 5.789 msec (+- 0.054 msec)
Average time per event: 0.568 usec (+- 0.005 usec)
Average memory usage: 11919 KB (+- 9 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 8.639 msec (+- 0.111 msec)
Average time per event: 0.847 usec (+- 0.011 usec)
Average memory usage: 12732 KB (+- 8 KB)
Average build-id-all injection took: 5.647 msec (+- 0.069 msec)
Average time per event: 0.554 usec (+- 0.007 usec)
Average memory usage: 12093 KB (+- 7 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 8.551 msec (+- 0.096 msec)
Average time per event: 0.838 usec (+- 0.009 usec)
Average memory usage: 12739 KB (+- 8 KB)
Average build-id-all injection took: 5.617 msec (+- 0.061 msec)
Average time per event: 0.551 usec (+- 0.006 usec)
Average memory usage: 12105 KB (+- 7 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 8.403 msec (+- 0.097 msec)
Average time per event: 0.824 usec (+- 0.010 usec)
Average memory usage: 12770 KB (+- 8 KB)
Average build-id-all injection took: 5.611 msec (+- 0.085 msec)
Average time per event: 0.550 usec (+- 0.008 usec)
Average memory usage: 12134 KB (+- 8 KB)
# Running 'internals/inject-build-id' benchmark:
Average build-id injection took: 8.518 msec (+- 0.102 msec)
Average time per event: 0.835 usec (+- 0.010 usec)
Average memory usage: 12518 KB (+- 10 KB)
Average build-id-all injection took: 5.503 msec (+- 0.073 msec)
Average time per event: 0.540 usec (+- 0.007 usec)
Average memory usage: 11882 KB (+- 8 KB)
Performance counter stats for 'perf bench internals inject-build-id' (5 runs):
2,394.88 msec task-clock:u # 1.577 CPUs utilized ( +- 0.83% )
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
103,181 page-faults:u # 0.043 M/sec ( +- 0.11% )
3,548,172,030 cycles:u # 1.482 GHz ( +- 0.30% ) (83.26%)
81,537,700 stalled-cycles-frontend:u # 2.30% frontend cycles idle ( +- 1.54% ) (83.24%)
876,631,544 stalled-cycles-backend:u # 24.71% backend cycles idle ( +- 1.14% ) (83.45%)
5,960,361,707 instructions:u # 1.68 insn per cycle
# 0.15 stalled cycles per insn ( +- 0.27% ) (83.26%)
1,269,413,491 branches:u # 530.054 M/sec ( +- 0.10% ) (83.48%)
11,372,453 branch-misses:u # 0.90% of all branches ( +- 0.52% ) (83.31%)
1.51874 +- 0.00642 seconds time elapsed ( +- 0.42% )
$
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lore.kernel.org/lkml/20201030054742.87740-1-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-10-30 05:47:42 +00:00
|
|
|
err = perf_data__read(session->data, p,
|
|
|
|
size - sizeof(struct perf_event_header));
|
2010-05-05 05:27:40 +00:00
|
|
|
if (err <= 0) {
|
|
|
|
if (err == 0) {
|
|
|
|
pr_err("unexpected end of event stream\n");
|
|
|
|
goto done;
|
|
|
|
}
|
2010-04-02 04:59:15 +00:00
|
|
|
|
2010-05-05 05:27:40 +00:00
|
|
|
pr_err("failed to read event data\n");
|
|
|
|
goto out_err;
|
|
|
|
}
|
2010-04-02 04:59:15 +00:00
|
|
|
}
|
|
|
|
|
2015-03-03 14:58:45 +00:00
|
|
|
if ((skip = perf_session__process_event(session, event, head)) < 0) {
|
2012-04-16 18:42:51 +00:00
|
|
|
pr_err("%#" PRIx64 " [%#x]: failed to process type: %d\n",
|
perf tools: Fix piped mode read code
In __perf_session__process_pipe_events(), there was a risk we would read
more than what a union perf_event struct can hold. this could happen in
case, perf is reading a file which contains new record types it does not
know about and which are larger than anything it knows about.
In general, perf is supposed to skip records it does not understand, but
in pipe mode, those have to be read and ignored. The fixed size header
contains the size of the record, but that size may be larger than union
perf_event, yet it was used as the backing to the read in:
union perf_event event;
void *p;
size = event->header.size;
p = &event;
p += sizeof(struct perf_event_header);
if (size - sizeof(struct perf_event_header)) {
err = readn(self->fd, p, size - sizeof(struct perf_event_header));
We fix this by allocating a buffer based on the size reported in the
header. We reuse the buffer as much as we can. We realloc in case it
becomes too small. In the common case, the performance impact is
negligible.
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1337081295-10303-3-git-send-email-eranian@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2012-05-15 11:28:12 +00:00
|
|
|
head, event->header.size, event->header.type);
|
2012-04-16 18:42:51 +00:00
|
|
|
err = -EINVAL;
|
|
|
|
goto out_err;
|
2010-04-02 04:59:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
head += size;
|
|
|
|
|
|
|
|
if (skip > 0)
|
|
|
|
head += skip;
|
|
|
|
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
err = __perf_session__process_decomp_events(session);
|
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
|
2010-04-02 04:59:15 +00:00
|
|
|
if (!session_done())
|
|
|
|
goto more;
|
|
|
|
done:
|
2013-10-18 12:29:02 +00:00
|
|
|
/* do the final flush for ordered samples */
|
2015-03-03 14:58:45 +00:00
|
|
|
err = ordered_events__flush(oe, OE_FLUSH__FINAL);
|
2015-04-09 15:53:48 +00:00
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
err = auxtrace__flush_events(session, tool);
|
2015-05-29 13:33:30 +00:00
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
err = perf_session__flush_thread_stacks(session);
|
2010-04-02 04:59:15 +00:00
|
|
|
out_err:
|
perf tools: Fix piped mode read code
In __perf_session__process_pipe_events(), there was a risk we would read
more than what a union perf_event struct can hold. this could happen in
case, perf is reading a file which contains new record types it does not
know about and which are larger than anything it knows about.
In general, perf is supposed to skip records it does not understand, but
in pipe mode, those have to be read and ignored. The fixed size header
contains the size of the record, but that size may be larger than union
perf_event, yet it was used as the backing to the read in:
union perf_event event;
void *p;
size = event->header.size;
p = &event;
p += sizeof(struct perf_event_header);
if (size - sizeof(struct perf_event_header)) {
err = readn(self->fd, p, size - sizeof(struct perf_event_header));
We fix this by allocating a buffer based on the size reported in the
header. We reuse the buffer as much as we can. We realloc in case it
becomes too small. In the common case, the performance impact is
negligible.
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1337081295-10303-3-git-send-email-eranian@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2012-05-15 11:28:12 +00:00
|
|
|
free(buf);
|
2018-01-07 16:03:54 +00:00
|
|
|
if (!tool->no_warn)
|
|
|
|
perf_session__warn_about_errors(session);
|
2014-06-10 20:50:03 +00:00
|
|
|
ordered_events__free(&session->ordered_events);
|
2015-04-09 15:53:48 +00:00
|
|
|
auxtrace__free_events(session);
|
2010-04-02 04:59:15 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2011-05-23 11:06:28 +00:00
|
|
|
static union perf_event *
|
2019-11-18 14:21:03 +00:00
|
|
|
prefetch_event(char *buf, u64 head, size_t mmap_size,
|
|
|
|
bool needs_swap, union perf_event *error)
|
2011-05-23 11:06:28 +00:00
|
|
|
{
|
|
|
|
union perf_event *event;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensure we have enough space remaining to read
|
|
|
|
* the size of the event in the headers.
|
|
|
|
*/
|
|
|
|
if (head + sizeof(event->header) > mmap_size)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
event = (union perf_event *)(buf + head);
|
2019-11-18 14:21:03 +00:00
|
|
|
if (needs_swap)
|
|
|
|
perf_event_header__bswap(&event->header);
|
2011-05-23 11:06:28 +00:00
|
|
|
|
2019-11-18 14:21:03 +00:00
|
|
|
if (head + event->header.size <= mmap_size)
|
|
|
|
return event;
|
|
|
|
|
|
|
|
/* We're not fetching the event so swap back again */
|
|
|
|
if (needs_swap)
|
2011-05-23 11:06:28 +00:00
|
|
|
perf_event_header__bswap(&event->header);
|
|
|
|
|
2019-11-18 14:21:03 +00:00
|
|
|
pr_debug("%s: head=%#" PRIx64 " event->header_size=%#x, mmap_size=%#zx:"
|
|
|
|
" fuzzed or compressed perf.data?\n",__func__, head, event->header.size, mmap_size);
|
2011-05-23 11:06:28 +00:00
|
|
|
|
2019-11-18 14:21:03 +00:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
static union perf_event *
|
|
|
|
fetch_mmaped_event(u64 head, size_t mmap_size, char *buf, bool needs_swap)
|
|
|
|
{
|
|
|
|
return prefetch_event(buf, head, mmap_size, needs_swap, ERR_PTR(-EINVAL));
|
|
|
|
}
|
|
|
|
|
|
|
|
static union perf_event *
|
|
|
|
fetch_decomp_event(u64 head, size_t mmap_size, char *buf, bool needs_swap)
|
|
|
|
{
|
|
|
|
return prefetch_event(buf, head, mmap_size, needs_swap, NULL);
|
2011-05-23 11:06:28 +00:00
|
|
|
}
|
|
|
|
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
static int __perf_session__process_decomp_events(struct perf_session *session)
|
|
|
|
{
|
|
|
|
s64 skip;
|
|
|
|
u64 size, file_pos = 0;
|
|
|
|
struct decomp *decomp = session->decomp_last;
|
|
|
|
|
|
|
|
if (!decomp)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
while (decomp->head < decomp->size && !session_done()) {
|
2019-11-18 14:21:03 +00:00
|
|
|
union perf_event *event = fetch_decomp_event(decomp->head, decomp->size, decomp->data,
|
|
|
|
session->header.needs_swap);
|
2019-07-30 13:58:41 +00:00
|
|
|
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
if (!event)
|
|
|
|
break;
|
|
|
|
|
|
|
|
size = event->header.size;
|
|
|
|
|
|
|
|
if (size < sizeof(struct perf_event_header) ||
|
|
|
|
(skip = perf_session__process_event(session, event, file_pos)) < 0) {
|
|
|
|
pr_err("%#" PRIx64 " [%#x]: failed to process type: %d\n",
|
|
|
|
decomp->file_pos + decomp->head, event->header.size, event->header.type);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (skip)
|
|
|
|
size += skip;
|
|
|
|
|
|
|
|
decomp->head += size;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-11-10 19:12:19 +00:00
|
|
|
/*
|
|
|
|
* On 64bit we can mmap the data file in one go. No need for tiny mmap
|
|
|
|
* slices. On 32bit we use 32MB.
|
|
|
|
*/
|
|
|
|
#if BITS_PER_LONG == 64
|
|
|
|
#define MMAP_SIZE ULLONG_MAX
|
|
|
|
#define NUM_MMAPS 1
|
|
|
|
#else
|
|
|
|
#define MMAP_SIZE (32 * 1024 * 1024ULL)
|
|
|
|
#define NUM_MMAPS 128
|
|
|
|
#endif
|
|
|
|
|
2019-03-08 13:47:40 +00:00
|
|
|
struct reader;
|
|
|
|
|
|
|
|
typedef s64 (*reader_cb_t)(struct perf_session *session,
|
|
|
|
union perf_event *event,
|
|
|
|
u64 file_offset);
|
|
|
|
|
2019-01-10 10:12:58 +00:00
|
|
|
struct reader {
|
2019-03-08 13:47:40 +00:00
|
|
|
int fd;
|
|
|
|
u64 data_size;
|
|
|
|
u64 data_offset;
|
|
|
|
reader_cb_t process;
|
2019-01-10 10:12:58 +00:00
|
|
|
};
|
|
|
|
|
2019-01-10 10:13:01 +00:00
|
|
|
static int
|
|
|
|
reader__process_events(struct reader *rd, struct perf_session *session,
|
|
|
|
struct ui_progress *prog)
|
2009-12-27 23:36:59 +00:00
|
|
|
{
|
2019-01-10 10:13:01 +00:00
|
|
|
u64 data_size = rd->data_size;
|
2014-07-23 19:19:58 +00:00
|
|
|
u64 head, page_offset, file_offset, file_pos, size;
|
2019-01-10 10:13:01 +00:00
|
|
|
int err = 0, mmap_prot, mmap_flags, map_idx = 0;
|
2012-10-06 17:57:10 +00:00
|
|
|
size_t mmap_size;
|
2012-11-10 19:12:19 +00:00
|
|
|
char *buf, *mmaps[NUM_MMAPS];
|
2011-01-29 16:01:45 +00:00
|
|
|
union perf_event *event;
|
2014-07-23 19:19:58 +00:00
|
|
|
s64 skip;
|
2010-11-30 17:49:38 +00:00
|
|
|
|
2019-01-10 10:13:01 +00:00
|
|
|
page_offset = page_size * (rd->data_offset / page_size);
|
2010-11-30 17:49:38 +00:00
|
|
|
file_offset = page_offset;
|
2019-01-10 10:13:01 +00:00
|
|
|
head = rd->data_offset - page_offset;
|
2009-12-27 23:36:59 +00:00
|
|
|
|
2019-01-10 10:13:01 +00:00
|
|
|
ui_progress__init_size(prog, data_size, "Processing events...");
|
perf record: Avoid infinite loop at buildid processing with no samples
If a session contains no events, we can get stuck in an infinite loop in
__perf_session__process_events, with a non-zero file_size and data_offset, but
a zero data_size.
In this case, we can mmap the entirety of the file (consisting of the file and
attribute headers), and fetch_mmaped_event will correctly refuse to read any
(unmapped and non-existent) event headers. This causes
__perf_session__process_events to unmap the file and retry with the exact same
parameters, getting stuck in an infinite loop.
This has been observed to result in an exit-time hang when counting
rare/unschedulable events with perf record, and can be triggered artificially
with the script below:
----
#!/bin/sh
printf "REPRO: launching perf\n";
./perf record -e software/config=9/ sleep 1 &
PERF_PID=$!;
sleep 0.002;
kill -2 $PERF_PID;
printf "REPRO: waiting for perf (%d) to exit...\n" "$PERF_PID";
wait $PERF_PID;
printf "REPRO: perf exited\n";
----
To avoid this, have __perf_session__process_events bail out early when
the file has no data (i.e. it has no events).
Commiter note:
I only managed to reproduce this when setting
/proc/sys/kernel/kptr_restrict to '1' and changing the code to
purposefully not process any samples and no synthesized samples, i.e.
kptr_restrict prevents 'record' from synthesizing the kernel mmaps for
vmlinux + modules and since it is a workload started from perf, we don't
synthesize mmap/comm records for existing threads.
Adrian Hunter managed to reproduce it in his environment tho.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Arnaldo Carvalho de Melo <acme@kernel.org>
Tested-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1442423929-12253-1-git-send-email-mark.rutland@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-09-16 17:18:49 +00:00
|
|
|
|
2019-01-10 10:13:01 +00:00
|
|
|
data_size += rd->data_offset;
|
2010-11-30 17:49:46 +00:00
|
|
|
|
2012-11-10 19:12:19 +00:00
|
|
|
mmap_size = MMAP_SIZE;
|
2019-01-10 10:12:57 +00:00
|
|
|
if (mmap_size > data_size) {
|
|
|
|
mmap_size = data_size;
|
2014-07-14 10:02:51 +00:00
|
|
|
session->one_mmap = true;
|
|
|
|
}
|
2010-11-30 17:49:46 +00:00
|
|
|
|
2010-11-30 17:49:49 +00:00
|
|
|
memset(mmaps, 0, sizeof(mmaps));
|
|
|
|
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
mmap_prot = PROT_READ;
|
|
|
|
mmap_flags = MAP_SHARED;
|
|
|
|
|
2010-11-30 17:49:38 +00:00
|
|
|
if (session->header.needs_swap) {
|
perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:
1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland
2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko
acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
acme@parisc:~/git/linux-2.6-tip$
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...
^^^^ The problem related to vmlinux handling, it shouldn't be trying this
^^^^ rather alien /proc/kallsyms at all...
/lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
/lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
/home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
/usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols
<SNIP more complaints about not finding the right build-ids,
those will have to wait for 'perf archive' or plain
copying what was collected by 'perf record' on the x86_64,
source machine, see further below for an example of this >
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:
[root@doppio linux-2.6-tip]# perf report --sort comm
# Samples: 293085637
#
# Overhead Command
# ........ ...............
#
61.70% find
23.50% perf
5.86% swapper
3.12% sshd
2.39% init
0.87% bash
0.86% sleep
0.59% dbus-daemon
0.25% hald
0.24% NetworkManager
0.19% hald-addon-rfki
0.15% openvpn
0.07% phy0
0.07% events/0
0.05% iwl3945
0.05% events/1
0.03% kondemand/0
[root@doppio linux-2.6-tip]#
The other modes work as well, modulo the problem with vmlinux:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object
# ........ ............... .................................
#
35.11% find ffffffff81002b5a
18.25% perf ffffffff8102235f
16.17% find libc-2.10.2.so
9.07% find find
5.80% swapper ffffffff8102235f
3.95% perf libc-2.10.2.so
2.33% init ffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k
1.35% find [e1000e]
0.68% sleep libc-2.10.2.so
acme@parisc:~/git/linux-2.6-tip$
And the lack of the right buildids:
acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
# Samples: 293085637
#
# Overhead Command Shared Object Symbol
# ........ ............... ................................. ......
#
35.11% find ffffffff81002b5a [k] 0xffffffff81002b5a
18.25% perf ffffffff8102235f [k] 0xffffffff8102235f
16.17% find libc-2.10.2.so [.] 0x00000000045782
9.07% find find [.] 0x0000000000fb0e
5.80% swapper ffffffff8102235f [k] 0xffffffff8102235f
3.95% perf libc-2.10.2.so [.] 0x0000000007f398
2.33% init ffffffff810091b9 [k] 0xffffffff810091b9
1.65% sshd libcrypto.so.0.9.8k [.] 0x00000000105440
1.35% find [e1000e] [k] 0x00000000010948
0.68% sleep libc-2.10.2.so [.] 0x0000000011ad5b
acme@parisc:~/git/linux-2.6-tip$
But if we:
acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
ls: cannot access /home/acme/.debug: No such file or directory
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
acme@doppio's password:
eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 100% 1783KB 714.7KB/s 00:02
acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
acme@parisc:~/git/linux-2.6-tip$
Which matches what we get on the source, F12, x86_64 machine:
[root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
# dso: libc-2.10.2.so
# Samples: 64281170
#
# Overhead Command Symbol
# ........ ............... ......
#
14.98% perf [.] __GI_strcmp
12.30% find [.] __GI_memmove
9.25% find [.] _int_malloc
7.60% find [.] _IO_vfprintf_internal
6.10% find [.] _IO_new_file_xsputn
6.02% find [.] __GI_close
3.08% find [.] _IO_file_overflow_internal
3.08% find [.] malloc_consolidate
3.08% find [.] _int_free
3.08% find [.] __strchrnul
3.08% find [.] __getdents64
3.08% find [.] __write_nocancel
3.08% sleep [.] __GI__dl_addr
3.08% sshd [.] __libc_select
3.08% find [.] _IO_new_file_write
3.07% find [.] _IO_new_do_write
3.06% find [.] __GI___errno_location
3.05% find [.] __GI___libc_malloc
3.04% perf [.] __GI_memcpy
1.71% find [.] __fprintf_chk
1.29% bash [.] __gconv_transform_utf8_internal
0.79% dbus-daemon [.] __GI_strlen
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[root@doppio linux-2.6-tip]#
So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)
There are some things to fix tho, like the bitmap on the header,
but things are looking good.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-14 14:23:10 +00:00
|
|
|
mmap_prot |= PROT_WRITE;
|
|
|
|
mmap_flags = MAP_PRIVATE;
|
|
|
|
}
|
2009-12-27 23:36:59 +00:00
|
|
|
remap:
|
2019-01-10 10:13:01 +00:00
|
|
|
buf = mmap(NULL, mmap_size, mmap_prot, mmap_flags, rd->fd,
|
2010-11-30 17:49:46 +00:00
|
|
|
file_offset);
|
2009-12-27 23:36:59 +00:00
|
|
|
if (buf == MAP_FAILED) {
|
|
|
|
pr_err("failed to mmap file\n");
|
|
|
|
err = -errno;
|
2019-01-10 10:13:01 +00:00
|
|
|
goto out;
|
2009-12-27 23:36:59 +00:00
|
|
|
}
|
2010-11-30 17:49:49 +00:00
|
|
|
mmaps[map_idx] = buf;
|
|
|
|
map_idx = (map_idx + 1) & (ARRAY_SIZE(mmaps) - 1);
|
2010-11-30 17:49:44 +00:00
|
|
|
file_pos = file_offset + head;
|
2014-07-14 10:02:51 +00:00
|
|
|
if (session->one_mmap) {
|
|
|
|
session->one_mmap_addr = buf;
|
|
|
|
session->one_mmap_offset = file_offset;
|
|
|
|
}
|
2009-12-27 23:36:59 +00:00
|
|
|
|
|
|
|
more:
|
2019-11-18 14:21:03 +00:00
|
|
|
event = fetch_mmaped_event(head, mmap_size, buf, session->header.needs_swap);
|
2019-07-30 13:58:41 +00:00
|
|
|
if (IS_ERR(event))
|
|
|
|
return PTR_ERR(event);
|
|
|
|
|
2011-05-23 11:06:28 +00:00
|
|
|
if (!event) {
|
2010-11-30 17:49:49 +00:00
|
|
|
if (mmaps[map_idx]) {
|
|
|
|
munmap(mmaps[map_idx], mmap_size);
|
|
|
|
mmaps[map_idx] = NULL;
|
|
|
|
}
|
2009-12-27 23:36:59 +00:00
|
|
|
|
2010-11-30 17:49:38 +00:00
|
|
|
page_offset = page_size * (head / page_size);
|
|
|
|
file_offset += page_offset;
|
|
|
|
head -= page_offset;
|
2009-12-27 23:36:59 +00:00
|
|
|
goto remap;
|
|
|
|
}
|
|
|
|
|
|
|
|
size = event->header.size;
|
|
|
|
|
2019-04-23 10:53:03 +00:00
|
|
|
skip = -EINVAL;
|
|
|
|
|
2013-07-04 13:20:27 +00:00
|
|
|
if (size < sizeof(struct perf_event_header) ||
|
2019-03-08 13:47:40 +00:00
|
|
|
(skip = rd->process(session, event, file_pos)) < 0) {
|
2019-04-23 10:53:03 +00:00
|
|
|
pr_err("%#" PRIx64 " [%#x]: failed to process type: %d [%s]\n",
|
2012-04-16 18:42:51 +00:00
|
|
|
file_offset + head, event->header.size,
|
2019-04-23 10:53:03 +00:00
|
|
|
event->header.type, strerror(-skip));
|
|
|
|
err = skip;
|
2019-01-10 10:13:01 +00:00
|
|
|
goto out;
|
2009-12-27 23:36:59 +00:00
|
|
|
}
|
|
|
|
|
2014-07-23 19:19:57 +00:00
|
|
|
if (skip)
|
|
|
|
size += skip;
|
|
|
|
|
2009-12-27 23:36:59 +00:00
|
|
|
head += size;
|
2010-11-30 17:49:44 +00:00
|
|
|
file_pos += size;
|
2009-12-27 23:36:59 +00:00
|
|
|
|
perf report: Implement perf.data record decompression
zstd_init(, comp_level = 0) initializes decompression part of API only
hat now consists of zstd_decompress_stream() function.
The perf.data PERF_RECORD_COMPRESSED records are decompressed using
zstd_decompress_stream() function into a linked list of mmaped memory
regions of mmap_comp_len size (struct decomp).
After decompression of one COMPRESSED record its content is iterated and
fetched for usual processing. The mmaped memory regions with
decompressed events are kept in the linked list till the tool process
termination.
When dumping raw records (e.g., perf report -D --header) file offsets of
events from compressed records are printed as zero.
Committer notes:
Since now we have support for processing PERF_RECORD_COMPRESSED, we see
none, in raw form, like we saw in the previous patch commiter notes,
they were decompressed into the usual PERF_RECORD_{FORK,MMAP,COMM,etc}
records, we only see the stats for those PERF_RECORD_COMPRESSED events,
and since I used the file generated in the commiter notes for the
previous patch, there they are, 2 compressed records:
$ perf report --header-only | grep cmdline
# cmdline : /home/acme/bin/perf record -z2 sleep 1
$ perf report -D | grep COMPRESS
COMPRESSED events: 2
COMPRESSED events: 0
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 15 of event 'cycles:u'
# Event count (approx.): 962227
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ...........................
#
46.99% sleep libc-2.28.so [.] _dl_addr
29.24% sleep [unknown] [k] 0xffffffffaea00a67
16.45% sleep libc-2.28.so [.] __GI__IO_un_link.part.1
5.92% sleep ld-2.28.so [.] _dl_setup_hash
1.40% sleep libc-2.28.so [.] __nanosleep
0.00% sleep [unknown] [k] 0xffffffffaea00163
#
# (Tip: To see callchains in a more compact form: perf report -g folded)
#
$
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/304b0a59-942c-3fe1-da02-aa749f87108b@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-03-18 17:45:11 +00:00
|
|
|
err = __perf_session__process_decomp_events(session);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
2019-01-10 10:13:01 +00:00
|
|
|
ui_progress__update(prog, size);
|
2010-11-30 17:49:46 +00:00
|
|
|
|
2013-09-17 19:34:28 +00:00
|
|
|
if (session_done())
|
2013-10-18 12:29:02 +00:00
|
|
|
goto out;
|
2013-09-17 19:34:28 +00:00
|
|
|
|
2019-01-10 10:12:57 +00:00
|
|
|
if (file_pos < data_size)
|
2009-12-27 23:36:59 +00:00
|
|
|
goto more;
|
2010-11-30 17:49:44 +00:00
|
|
|
|
2013-10-18 12:29:02 +00:00
|
|
|
out:
|
2019-01-10 10:13:01 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2019-03-08 13:47:40 +00:00
|
|
|
static s64 process_simple(struct perf_session *session,
|
|
|
|
union perf_event *event,
|
|
|
|
u64 file_offset)
|
|
|
|
{
|
|
|
|
return perf_session__process_event(session, event, file_offset);
|
|
|
|
}
|
|
|
|
|
2019-01-10 10:13:01 +00:00
|
|
|
static int __perf_session__process_events(struct perf_session *session)
|
|
|
|
{
|
|
|
|
struct reader rd = {
|
|
|
|
.fd = perf_data__fd(session->data),
|
|
|
|
.data_size = session->header.data_size,
|
|
|
|
.data_offset = session->header.data_offset,
|
2019-03-08 13:47:40 +00:00
|
|
|
.process = process_simple,
|
2019-01-10 10:13:01 +00:00
|
|
|
};
|
|
|
|
struct ordered_events *oe = &session->ordered_events;
|
|
|
|
struct perf_tool *tool = session->tool;
|
|
|
|
struct ui_progress prog;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
perf_tool__fill_defaults(tool);
|
|
|
|
|
|
|
|
if (rd.data_size == 0)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
ui_progress__init_size(&prog, rd.data_size, "Processing events...");
|
|
|
|
|
|
|
|
err = reader__process_events(&rd, session, &prog);
|
|
|
|
if (err)
|
|
|
|
goto out_err;
|
2010-04-23 22:04:12 +00:00
|
|
|
/* do the final flush for ordered samples */
|
2015-03-03 14:58:45 +00:00
|
|
|
err = ordered_events__flush(oe, OE_FLUSH__FINAL);
|
2015-04-09 15:53:48 +00:00
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
err = auxtrace__flush_events(session, tool);
|
2015-05-29 13:33:30 +00:00
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
err = perf_session__flush_thread_stacks(session);
|
2009-12-27 23:36:59 +00:00
|
|
|
out_err:
|
2012-11-13 13:30:34 +00:00
|
|
|
ui_progress__finish();
|
2018-01-07 16:03:54 +00:00
|
|
|
if (!tool->no_warn)
|
|
|
|
perf_session__warn_about_errors(session);
|
2016-04-13 08:21:04 +00:00
|
|
|
/*
|
|
|
|
* We may switching perf.data output, make ordered_events
|
|
|
|
* reusable.
|
|
|
|
*/
|
|
|
|
ordered_events__reinit(&session->ordered_events);
|
2015-04-09 15:53:48 +00:00
|
|
|
auxtrace__free_events(session);
|
2014-07-14 10:02:51 +00:00
|
|
|
session->one_mmap = false;
|
2009-12-27 23:36:59 +00:00
|
|
|
return err;
|
|
|
|
}
|
2009-12-27 23:37:01 +00:00
|
|
|
|
2015-03-03 14:58:45 +00:00
|
|
|
int perf_session__process_events(struct perf_session *session)
|
2010-02-03 18:52:05 +00:00
|
|
|
{
|
2015-12-09 02:11:23 +00:00
|
|
|
if (perf_session__register_idle_thread(session) < 0)
|
2010-02-03 18:52:05 +00:00
|
|
|
return -ENOMEM;
|
|
|
|
|
2019-01-10 10:12:56 +00:00
|
|
|
if (perf_data__is_pipe(session->data))
|
|
|
|
return __perf_session__process_pipe_events(session);
|
2010-07-27 14:46:12 +00:00
|
|
|
|
2019-01-10 10:12:56 +00:00
|
|
|
return __perf_session__process_events(session);
|
2010-02-03 18:52:05 +00:00
|
|
|
}
|
|
|
|
|
2012-08-01 22:15:52 +00:00
|
|
|
bool perf_session__has_traces(struct perf_session *session, const char *msg)
|
2009-12-27 23:37:01 +00:00
|
|
|
{
|
2019-07-21 11:23:51 +00:00
|
|
|
struct evsel *evsel;
|
2013-08-08 02:50:58 +00:00
|
|
|
|
2016-06-23 14:26:15 +00:00
|
|
|
evlist__for_each_entry(session->evlist, evsel) {
|
2019-07-21 11:24:29 +00:00
|
|
|
if (evsel->core.attr.type == PERF_TYPE_TRACEPOINT)
|
2013-08-08 02:50:58 +00:00
|
|
|
return true;
|
2009-12-27 23:37:01 +00:00
|
|
|
}
|
|
|
|
|
2013-08-08 02:50:58 +00:00
|
|
|
pr_err("No trace sample to read. Did you call 'perf %s'?\n", msg);
|
|
|
|
return false;
|
2009-12-27 23:37:01 +00:00
|
|
|
}
|
2010-01-05 18:50:31 +00:00
|
|
|
|
2018-04-26 19:52:34 +00:00
|
|
|
int map__set_kallsyms_ref_reloc_sym(struct map *map, const char *symbol_name, u64 addr)
|
2010-01-05 18:50:31 +00:00
|
|
|
{
|
|
|
|
char *bracket;
|
2010-04-19 05:32:50 +00:00
|
|
|
struct ref_reloc_sym *ref;
|
2018-04-26 19:52:34 +00:00
|
|
|
struct kmap *kmap;
|
2010-04-19 05:32:50 +00:00
|
|
|
|
|
|
|
ref = zalloc(sizeof(struct ref_reloc_sym));
|
|
|
|
if (ref == NULL)
|
|
|
|
return -ENOMEM;
|
2010-01-05 18:50:31 +00:00
|
|
|
|
2010-04-19 05:32:50 +00:00
|
|
|
ref->name = strdup(symbol_name);
|
|
|
|
if (ref->name == NULL) {
|
|
|
|
free(ref);
|
2010-01-05 18:50:31 +00:00
|
|
|
return -ENOMEM;
|
2010-04-19 05:32:50 +00:00
|
|
|
}
|
2010-01-05 18:50:31 +00:00
|
|
|
|
2010-04-19 05:32:50 +00:00
|
|
|
bracket = strchr(ref->name, ']');
|
2010-01-05 18:50:31 +00:00
|
|
|
if (bracket)
|
|
|
|
*bracket = '\0';
|
|
|
|
|
2010-04-19 05:32:50 +00:00
|
|
|
ref->addr = addr;
|
2010-02-03 18:52:00 +00:00
|
|
|
|
2018-04-26 19:52:34 +00:00
|
|
|
kmap = map__kmap(map);
|
|
|
|
if (kmap)
|
2010-04-19 05:32:50 +00:00
|
|
|
kmap->ref_reloc_sym = ref;
|
2010-02-03 18:52:00 +00:00
|
|
|
|
2010-01-05 18:50:31 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2010-05-09 22:57:08 +00:00
|
|
|
|
2013-11-05 18:32:36 +00:00
|
|
|
size_t perf_session__fprintf_dsos(struct perf_session *session, FILE *fp)
|
2010-05-09 22:57:08 +00:00
|
|
|
{
|
2013-11-05 18:32:36 +00:00
|
|
|
return machines__fprintf_dsos(&session->machines, fp);
|
2010-05-09 22:57:08 +00:00
|
|
|
}
|
2010-05-19 16:41:23 +00:00
|
|
|
|
2013-11-05 18:32:36 +00:00
|
|
|
size_t perf_session__fprintf_dsos_buildid(struct perf_session *session, FILE *fp,
|
2012-12-07 12:53:58 +00:00
|
|
|
bool (skip)(struct dso *dso, int parm), int parm)
|
2010-05-19 16:41:23 +00:00
|
|
|
{
|
2013-11-05 18:32:36 +00:00
|
|
|
return machines__fprintf_dsos_buildid(&session->machines, fp, skip, parm);
|
2010-05-19 16:41:23 +00:00
|
|
|
}
|
2011-03-06 00:40:06 +00:00
|
|
|
|
|
|
|
size_t perf_session__fprintf_nr_events(struct perf_session *session, FILE *fp)
|
|
|
|
{
|
2015-04-09 15:53:48 +00:00
|
|
|
size_t ret;
|
|
|
|
const char *msg = "";
|
|
|
|
|
|
|
|
if (perf_header__has_feat(&session->header, HEADER_AUXTRACE))
|
|
|
|
msg = " (excludes AUX area (e.g. instruction trace) decoded / synthesized events)";
|
|
|
|
|
2015-06-23 07:52:49 +00:00
|
|
|
ret = fprintf(fp, "\nAggregated stats:%s\n", msg);
|
2011-03-06 00:40:06 +00:00
|
|
|
|
2015-02-14 17:50:11 +00:00
|
|
|
ret += events_stats__fprintf(&session->evlist->stats, fp);
|
2011-03-06 00:40:06 +00:00
|
|
|
return ret;
|
|
|
|
}
|
2011-03-10 05:23:27 +00:00
|
|
|
|
2011-11-09 15:24:25 +00:00
|
|
|
size_t perf_session__fprintf(struct perf_session *session, FILE *fp)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* FIXME: Here we have to actually print all the machines in this
|
|
|
|
* session, not just the host...
|
|
|
|
*/
|
2012-12-18 22:15:48 +00:00
|
|
|
return machine__fprintf(&session->machines.host, fp);
|
2011-11-09 15:24:25 +00:00
|
|
|
}
|
|
|
|
|
2019-07-21 11:23:51 +00:00
|
|
|
struct evsel *perf_session__find_first_evtype(struct perf_session *session,
|
2011-04-07 03:54:20 +00:00
|
|
|
unsigned int type)
|
|
|
|
{
|
2019-07-21 11:23:51 +00:00
|
|
|
struct evsel *pos;
|
2011-04-07 03:54:20 +00:00
|
|
|
|
2016-06-23 14:26:15 +00:00
|
|
|
evlist__for_each_entry(session->evlist, pos) {
|
2019-07-21 11:24:29 +00:00
|
|
|
if (pos->core.attr.type == type)
|
2011-04-07 03:54:20 +00:00
|
|
|
return pos;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2011-07-04 11:57:50 +00:00
|
|
|
int perf_session__cpu_bitmap(struct perf_session *session,
|
|
|
|
const char *cpu_list, unsigned long *cpu_bitmap)
|
|
|
|
{
|
2014-01-20 11:39:39 +00:00
|
|
|
int i, err = -1;
|
2019-07-21 11:23:49 +00:00
|
|
|
struct perf_cpu_map *map;
|
2021-01-07 17:41:59 +00:00
|
|
|
int nr_cpus = min(session->header.env.nr_cpus_avail, MAX_NR_CPUS);
|
2011-07-04 11:57:50 +00:00
|
|
|
|
|
|
|
for (i = 0; i < PERF_TYPE_MAX; ++i) {
|
2019-07-21 11:23:51 +00:00
|
|
|
struct evsel *evsel;
|
2011-07-04 11:57:50 +00:00
|
|
|
|
|
|
|
evsel = perf_session__find_first_evtype(session, i);
|
|
|
|
if (!evsel)
|
|
|
|
continue;
|
|
|
|
|
2019-07-21 11:24:29 +00:00
|
|
|
if (!(evsel->core.attr.sample_type & PERF_SAMPLE_CPU)) {
|
2011-07-04 11:57:50 +00:00
|
|
|
pr_err("File does not contain CPU events. "
|
2017-05-26 08:17:19 +00:00
|
|
|
"Remove -C option to proceed.\n");
|
2011-07-04 11:57:50 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-07-21 11:24:30 +00:00
|
|
|
map = perf_cpu_map__new(cpu_list);
|
2011-11-13 17:45:27 +00:00
|
|
|
if (map == NULL) {
|
|
|
|
pr_err("Invalid cpu_list\n");
|
|
|
|
return -1;
|
|
|
|
}
|
2011-07-04 11:57:50 +00:00
|
|
|
|
|
|
|
for (i = 0; i < map->nr; i++) {
|
|
|
|
int cpu = map->map[i];
|
|
|
|
|
2019-08-27 21:43:49 +00:00
|
|
|
if (cpu >= nr_cpus) {
|
2011-07-04 11:57:50 +00:00
|
|
|
pr_err("Requested CPU %d too large. "
|
|
|
|
"Consider raising MAX_NR_CPUS\n", cpu);
|
2014-01-20 11:39:39 +00:00
|
|
|
goto out_delete_map;
|
2011-07-04 11:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
set_bit(cpu, cpu_bitmap);
|
|
|
|
}
|
|
|
|
|
2014-01-20 11:39:39 +00:00
|
|
|
err = 0;
|
|
|
|
|
|
|
|
out_delete_map:
|
2019-07-21 11:24:17 +00:00
|
|
|
perf_cpu_map__put(map);
|
2014-01-20 11:39:39 +00:00
|
|
|
return err;
|
2011-07-04 11:57:50 +00:00
|
|
|
}
|
perf tools: Make perf.data more self-descriptive (v8)
The goal of this patch is to include more information about the host
environment into the perf.data so it is more self-descriptive. Overtime,
profiles are captured on various machines and it becomes hard to track
what was recorded, on what machine and when.
This patch provides a way to solve this by extending the perf.data file
with basic information about the host machine. To add those extensions,
we leverage the feature bits capabilities of the perf.data format. The
change is backward compatible with existing perf.data files.
We define the following useful new extensions:
- HEADER_HOSTNAME: the hostname
- HEADER_OSRELEASE: the kernel release number
- HEADER_ARCH: the hw architecture
- HEADER_CPUDESC: generic CPU description
- HEADER_NRCPUS: number of online/avail cpus
- HEADER_CMDLINE: perf command line
- HEADER_VERSION: perf version
- HEADER_TOPOLOGY: cpu topology
- HEADER_EVENT_DESC: full event description (attrs)
- HEADER_CPUID: easy-to-parse low level CPU identication
The small granularity for the entries is to make it easier to extend
without breaking backward compatiblity. Many entries are provided as
ASCII strings.
Perf report/script have been modified to print the basic information as
easy-to-parse ASCII strings. Extended information about CPU and NUMA
topology may be requested with the -I option.
Thanks to David Ahern for reviewing and testing the many versions of
this patch.
$ perf report --stdio
# ========
# captured on : Mon Sep 26 15:22:14 2011
# hostname : quad
# os release : 3.1.0-rc4-tip
# perf version : 3.1.0-rc4
# arch : x86_64
# nrcpus online : 4
# nrcpus avail : 4
# cpudesc : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
# cpuid : GenuineIntel,6,15,11
# total memory : 8105360 kB
# cmdline : /home/eranian/perfmon/official/tip/build/tools/perf/perf record date
# event : name = cycles, type = 0, config = 0x0, config1 = 0x0, config2 = 0x0, excl_usr = 0, excl_kern = 0, id = { 29, 30, 31,
# HEADER_CPU_TOPOLOGY info available, use -I to display
# HEADER_NUMA_TOPOLOGY info available, use -I to display
# ========
#
...
$ perf report --stdio -I
# ========
# captured on : Mon Sep 26 15:22:14 2011
# hostname : quad
# os release : 3.1.0-rc4-tip
# perf version : 3.1.0-rc4
# arch : x86_64
# nrcpus online : 4
# nrcpus avail : 4
# cpudesc : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
# cpuid : GenuineIntel,6,15,11
# total memory : 8105360 kB
# cmdline : /home/eranian/perfmon/official/tip/build/tools/perf/perf record date
# event : name = cycles, type = 0, config = 0x0, config1 = 0x0, config2 = 0x0, excl_usr = 0, excl_kern = 0, id = { 29, 30, 31,
# sibling cores : 0-3
# sibling threads : 0
# sibling threads : 1
# sibling threads : 2
# sibling threads : 3
# node0 meminfo : total = 8320608 kB, free = 7571024 kB
# node0 cpu list : 0-3
# ========
#
...
Reviewed-by: David Ahern <dsahern@gmail.com>
Tested-by: David Ahern <dsahern@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/20110930134040.GA5575@quad
Signed-off-by: Stephane Eranian <eranian@google.com>
[ committer notes: Use --show-info in the tools as was in the docs, rename
perf_header_fprintf_info to perf_file_section__fprintf_info, fixup
conflict with f69b64f7 "perf: Support setting the disassembler style" ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-09-30 13:40:40 +00:00
|
|
|
|
|
|
|
void perf_session__fprintf_info(struct perf_session *session, FILE *fp,
|
|
|
|
bool full)
|
|
|
|
{
|
|
|
|
if (session == NULL || fp == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
fprintf(fp, "# ========\n");
|
|
|
|
perf_header__fprintf_info(session, fp, full);
|
|
|
|
fprintf(fp, "# ========\n#\n");
|
|
|
|
}
|
2012-06-27 16:08:42 +00:00
|
|
|
|
2018-09-13 12:54:03 +00:00
|
|
|
int perf_event__process_id_index(struct perf_session *session,
|
|
|
|
union perf_event *event)
|
2014-10-27 13:49:22 +00:00
|
|
|
{
|
2019-07-21 11:23:52 +00:00
|
|
|
struct evlist *evlist = session->evlist;
|
2019-08-28 13:57:16 +00:00
|
|
|
struct perf_record_id_index *ie = &event->id_index;
|
2014-10-27 13:49:22 +00:00
|
|
|
size_t i, nr, max_nr;
|
|
|
|
|
2019-08-28 13:57:16 +00:00
|
|
|
max_nr = (ie->header.size - sizeof(struct perf_record_id_index)) /
|
2014-10-27 13:49:22 +00:00
|
|
|
sizeof(struct id_index_entry);
|
|
|
|
nr = ie->nr;
|
|
|
|
if (nr > max_nr)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (dump_trace)
|
|
|
|
fprintf(stdout, " nr: %zu\n", nr);
|
|
|
|
|
|
|
|
for (i = 0; i < nr; i++) {
|
|
|
|
struct id_index_entry *e = &ie->entries[i];
|
|
|
|
struct perf_sample_id *sid;
|
|
|
|
|
|
|
|
if (dump_trace) {
|
2019-08-28 13:57:01 +00:00
|
|
|
fprintf(stdout, " ... id: %"PRI_lu64, e->id);
|
|
|
|
fprintf(stdout, " idx: %"PRI_lu64, e->idx);
|
|
|
|
fprintf(stdout, " cpu: %"PRI_ld64, e->cpu);
|
|
|
|
fprintf(stdout, " tid: %"PRI_ld64"\n", e->tid);
|
2014-10-27 13:49:22 +00:00
|
|
|
}
|
|
|
|
|
2020-11-30 17:17:57 +00:00
|
|
|
sid = evlist__id2sid(evlist, e->id);
|
2014-10-27 13:49:22 +00:00
|
|
|
if (!sid)
|
|
|
|
return -ENOENT;
|
|
|
|
sid->idx = e->idx;
|
|
|
|
sid->cpu = e->cpu;
|
|
|
|
sid->tid = e->tid;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|