perf/urgent fixes for 4.12
Arnaldo Carvalho de Melo
maintainerHi Ingo,
Please consider pulling,
- Arnaldo
Test results at the end of this message, as usual.
The following changes since commit 47c1ded7fef108c730b803cd386241beffcdd15c:
Merge tag 'perf-urgent-for-mingo-4.12-20170608' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent (2017-06-09 00:41:33 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-4.12-20170613
for you to fetch changes up to 9e0c6fd15fcaea39784d1fb3e9fc573f1cf0ae60:
perf tools: Fix build with ARCH=x86_64 (2017-06-13 16:20:37 -0300)
----------------------------------------------------------------
perf/urgent fixes:
- Fix probing of precise_ip level for default cycles event, that got broken recently on x86_64 when its arch code started considering invalid requesting precise samples when not sampling (i.e. when attr.sample_period == 0).
This also fixes another problem in s/390 where the precision probing with sample_period == 0 returned precise_ip > 0, that then, when setting up the real cycles event (not probing) would return EOPNOTSUPP for precise_ip > 0 (as determined previously by probing) and sample_period > 0.
These problems resulted in attr_precise not being set to the highest precision available on x86.64 when no event was specified, i.e. the canonical:
perf record ./workload
would end up using attr.precise_ip = 0. As a workaround this would need to be done:
perf record -e cycles:P ./workload
And on s/390 it would plain not work, requiring using:
perf record -e cycles ./workload
as a workaround. (Arnaldo Carvalho de Melo)
- Fix perf build with ARCH=x86_64, when ARCH should be transformed into ARCH=x86, just like with the main kernel Makefile and tools/objtool's, i.e. use SRCARCH. (Jiada Wang)
----------------------------------------------------------------
Arnaldo Carvalho de Melo (1):
perf evsel: Fix probing of precise_ip level for default cycles event
Jiada Wang (1):
perf tools: Fix build with ARCH=x86_64
tools/perf/Makefile.config | 38 +++++++++++++++++++------------------- tools/perf/Makefile.perf | 2 +- tools/perf/arch/Build | 2 +- tools/perf/pmu-events/Build | 4 ++-- tools/perf/tests/Build | 2 +- tools/perf/tests/task-exit.c | 2 +- tools/perf/util/evsel.c | 5 +++++ tools/perf/util/header.c | 2 +- 8 files changed, 31 insertions(+), 26 deletions(-)
Test results:
The first ones are container (docker) based builds of tools/perf with and without libelf support, objtool where it is supported and samples/bpf/, ditto. Where clang is available, it is also used to build perf with/without libelf.
Several are cross builds, the ones with -x-ARCH, and the android one, and those may not have all the features built, due to lack of multi-arch devel packages, available and being used so far on just a few, like debian:experimental-x-{arm64,mipsel}.
The 'perf test' one will perform a variety of tests exercising tools/perf/util/, tools/lib/{bpf,traceevent,etc}, as well as run perf commands with a variety of command line event specifications to then intercept the sys_perf_event syscall to check that the perf_event_attr fields are set up as expected, among a variety of other unit tests.
Then there is the 'make -C tools/perf build-test' ones, that build tools/perf/ with a variety of feature sets, exercising the build with an incomplete set of features as well as with a complete one. It is planned to have it run on each of the containers mentioned above, using some container orchestration infrastructure. Get in contact if interested in helping having this in place.
# dm 1 alpine:3.4: Ok 2 alpine:3.5: Ok 3 alpine:3.6: Ok 4 alpine:edge: Ok 5 android-ndk:r12b-arm: Ok 6 archlinux:latest: Ok 7 centos:5: Ok 8 centos:6: Ok 9 centos:7: Ok 10 debian:7: Ok 11 debian:8: Ok 12 debian:9: Ok 13 debian:experimental: Ok 14 debian:experimental-x-arm64: Ok 15 debian:experimental-x-mips: Ok 16 debian:experimental-x-mips64: Ok 17 debian:experimental-x-mipsel: Ok 18 fedora:20: Ok 19 fedora:21: Ok 20 fedora:22: Ok 21 fedora:23: Ok 22 fedora:24: Ok 23 fedora:24-x-ARC-uClibc: Ok 24 fedora:25: Ok 25 fedora:rawhide: Ok 26 mageia:5: Ok 27 opensuse:13.2: Ok 28 opensuse:42.1: Ok 29 opensuse:tumbleweed: Ok 30 ubuntu:12.04.5: Ok 31 ubuntu:14.04.4: Ok 32 ubuntu:14.04.4-x-linaro-arm64: Ok 33 ubuntu:15.10: Ok 34 ubuntu:16.04: Ok 35 ubuntu:16.04-x-arm: Ok 36 ubuntu:16.04-x-arm64: Ok 37 ubuntu:16.04-x-powerpc: Ok 38 ubuntu:16.04-x-powerpc64: Ok 39 ubuntu:16.04-x-powerpc64el: Ok 40 ubuntu:16.04-x-s390: Ok 41 ubuntu:16.10: Ok 42 ubuntu:17.04: Ok #
# uname -a Linux jouet 4.12.0-rc4+ #1 SMP Fri Jun 9 12:59:23 -03 2017 x86_64 x86_64 x86_64 GNU/Linux # perf test 1: vmlinux symtab matches kallsyms : Ok 2: Detect openat syscall event : Ok 3: Detect openat syscall event on all cpus : Ok 4: Read samples using the mmap interface : Ok 5: Parse event definition strings : Ok 6: Simple expression parser : Ok 7: PERF_RECORD_* events & perf_sample fields : Ok 8: Parse perf pmu format : Ok 9: DSO data read : Ok 10: DSO data cache : Ok 11: DSO data reopen : Ok 12: Roundtrip evsel->name : Ok 13: Parse sched tracepoints fields : Ok 14: syscalls:sys_enter_openat event fields : Ok 15: Setup struct perf_event_attr : Ok 16: Match and link multiple hists : Ok 17: 'import perf' in python : Ok 18: Breakpoint overflow signal handler : Ok 19: Breakpoint overflow sampling : Ok 20: Number of exit events of a simple workload : Ok 21: Software clock events period values : Ok 22: Object code reading : Ok 23: Sample parsing : Ok 24: Use a dummy software event to keep tracking: Ok 25: Parse with no sample_id_all bit set : Ok 26: Filter hist entries : Ok 27: Lookup mmap thread : Ok 28: Share thread mg : Ok 29: Sort output of hist entries : Ok 30: Cumulate child hist entries : Ok 31: Track with sched_switch : Ok 32: Filter fds with revents mask in a fdarray : Ok 33: Add fd to a fdarray, making it autogrow : Ok 34: kmod_path__parse : Ok 35: Thread map : Ok 36: LLVM search and compile : 36.1: Basic BPF llvm compile : Ok 36.2: kbuild searching : Ok 36.3: Compile source for BPF prologue generation: Ok 36.4: Compile source for BPF relocation : Ok 37: Session topology : Ok 38: BPF filter : 38.1: Basic BPF filtering : Ok 38.2: BPF pinning : Ok 38.3: BPF prologue generation : Ok 38.4: BPF relocation checker : Ok 39: Synthesize thread map : Ok 40: Remove thread map : Ok 41: Synthesize cpu map : Ok 42: Synthesize stat config : Ok 43: Synthesize stat : Ok 44: Synthesize stat round : Ok 45: Synthesize attr update : Ok 46: Event times : Ok 47: Read backward ring buffer : Ok 48: Print cpu map : Ok 49: Probe SDT events : Ok 50: is_printable_array : Ok 51: Print bitmap : Ok 52: perf hooks : Ok 53: builtin clang support : Skip (not compiled in) 54: unit_number__scnprintf : Ok 55: x86 rdpmc : Ok 56: Convert perf time to TSC : Ok 57: DWARF unwind : Ok 58: x86 instruction decoder - new instructions : Ok 59: Intel cqm nmi context read : Skip #
$ make -C tools/perf build-test
make: Entering directory '/home/acme/git/linux/tools/perf'
- tarpkg: ./tests/perf-targz-src-pkg .
make_no_libaudit_O: make NO_LIBAUDIT=1
make_minimal_O: make NO_LIBPERL=1 NO_LIBPYTHON=1 NO_NEWT=1 NO_GTK2=1 NO_DEMANGLE=1 NO_LIBELF=1 NO_LIBUNWIND=1 NO_BACKTRACE=1 NO_LIBNUMA=1 NO_LIBAUDIT=1 NO_LIBBIONIC=1 NO_LIBDW_DWARF_UNWIND=1 NO_AUXTRACE=1 NO_LIBBPF=1 NO_LIBCRYPTO=1 NO_SDT=1 NO_JVMTI=1
make_with_clangllvm_O: make LIBCLANGLLVM=1
make_clean_all_O: make clean all
make_no_slang_O: make NO_SLANG=1
make_help_O: make help
make_install_prefix_slash_O: make install prefix=/tmp/krava/
make_no_libunwind_O: make NO_LIBUNWIND=1
make_no_scripts_O: make NO_LIBPYTHON=1 NO_LIBPERL=1
make_with_babeltrace_O: make LIBBABELTRACE=1
make_install_O: make install
make_no_libelf_O: make NO_LIBELF=1
make_doc_O: make doc
make_no_libdw_dwarf_unwind_O: make NO_LIBDW_DWARF_UNWIND=1
make_tags_O: make tags
make_no_libnuma_O: make NO_LIBNUMA=1
make_no_demangle_O: make NO_DEMANGLE=1
make_no_auxtrace_O: make NO_AUXTRACE=1
make_no_libbpf_O: make NO_LIBBPF=1
make_no_libbionic_O: make NO_LIBBIONIC=1
make_no_libpython_O: make NO_LIBPYTHON=1
make_no_libperl_O: make NO_LIBPERL=1
make_util_pmu_bison_o_O: make util/pmu-bison.o
make_no_gtk2_O: make NO_GTK2=1
make_install_bin_O: make install-bin
make_no_ui_O: make NO_NEWT=1 NO_SLANG=1 NO_GTK2=1
make_debug_O: make DEBUG=1
make_util_map_o_O: make util/map.o
make_install_prefix_O: make install prefix=/tmp/krava
make_pure_O: make
make_no_backtrace_O: make NO_BACKTRACE=1
cd . && make FEATURE_DUMP_COPY=/home/acme/git/linux/tools/perf/BUILD_TEST_FEATURE_DUMP_STATIC LDFLAGS='-static' feature-dump
make_static_O: make LDFLAGS=-static
make_perf_o_O: make perf.o
make_no_newt_O: make NO_NEWT=1
OK
$Arnaldo Carvalho de Melo
maintainerPATCH 1/2 perf evsel: Fix probing of precise_ip level for default cycles event
From: Arnaldo Carvalho de Melo <[email protected]>
Since commit 18e7a45af91a ("perf/x86: Reject non sampling events with precise_ip") returns -EINVAL for sys_perf_event_open() with an attribute with (attr.precise_ip > 0 && attr.sample_period == 0), just like is done in the routine used to probe the max precise level when no events were passed to 'perf record' or 'perf top', i.e.:
perf_evsel__new_cycles()
perf_event_attr__set_max_precise_ip()
The x86 code, in x86_pmu_hw_config(), which is called all the way from sys_perf_event_open() did, starting with the aforementioned commit:
/* There's no sense in having PEBS for non sampling events: */
if (!is_sampling_event(event))
return -EINVAL;Which makes it fail for cycles:ppp, cycles:pp and cycles:p, always using just the non precise cycles variant.
To make sure that this is the case, I tested it, before this patch, with:
# perf probe -L x86_pmu_hw_config
<x86_pmu_hw_config@/home/acme/git/linux/arch/x86/events/core.c:0>
0 int x86_pmu_hw_config(struct perf_event *event)
1 {
2 if (event->attr.precise_ip) {
<SNIP>
17 if (event->attr.precise_ip > precise)
18 return -EOPNOTSUPP; /* There's no sense in having PEBS for non sampling events: */
21 if (!is_sampling_event(event))
22 return -EINVAL;
}
<SNIP>
# perf probe x86_pmu_hw_config:22
Added new events:
probe:x86_pmu_hw_config (on x86_pmu_hw_config:22)
probe:x86_pmu_hw_config_1 (on x86_pmu_hw_config:22)You can now use it in all perf tools, such as:
perf record -e probe:x86_pmu_hw_config_1 -aR sleep 1
# perf trace -e perf_event_open,probe:x86_pmu_hwconfig*/max-stack=16/ perf record usleep 1
0.000 ( 0.015 ms): perf/4150 perf_event_open(attr_uptr: 0x7ffebc8ba110, cpu: -1, group_fd: -1 ) ...
0.015 ( ): probe:x86_pmu_hw_config:(ffffffff9c0065e1))
x86_pmu_hw_config ([kernel.kallsyms])
hsw_hw_config ([kernel.kallsyms])
x86_pmu_event_init ([kernel.kallsyms])
perf_try_init_event ([kernel.kallsyms])
perf_event_alloc ([kernel.kallsyms])
SYSC_perf_event_open ([kernel.kallsyms])
sys_perf_event_open ([kernel.kallsyms])
do_syscall_64 ([kernel.kallsyms])
return_from_SYSCALL_64 ([kernel.kallsyms])
syscall (/usr/lib64/libc-2.24.so)
perf_event_attr__set_max_precise_ip (/home/acme/bin/perf)
perf_evsel__new_cycles (/home/acme/bin/perf)
perf_evlist__add_default (/home/acme/bin/perf)
cmd_record (/home/acme/bin/perf)
run_builtin (/home/acme/bin/perf)
handle_internal_command (/home/acme/bin/perf)
0.000 ( 0.021 ms): perf/4150 ... [continued]: perf_event_open()) = -1 EINVAL Invalid argument
0.023 ( 0.002 ms): perf/4150 perf_event_open(attr_uptr: 0x7ffebc8ba110, cpu: -1, group_fd: -1 ) ...
0.025 ( ): probe:x86_pmu_hw_config:(ffffffff9c0065e1))
x86_pmu_hw_config ([kernel.kallsyms])
hsw_hw_config ([kernel.kallsyms])
x86_pmu_event_init ([kernel.kallsyms])
perf_try_init_event ([kernel.kallsyms])
perf_event_alloc ([kernel.kallsyms])
SYSC_perf_event_open ([kernel.kallsyms])
sys_perf_event_open ([kernel.kallsyms])
do_syscall_64 ([kernel.kallsyms])
return_from_SYSCALL_64 ([kernel.kallsyms])
syscall (/usr/lib64/libc-2.24.so)
perf_event_attr__set_max_precise_ip (/home/acme/bin/perf)
perf_evsel__new_cycles (/home/acme/bin/perf)
perf_evlist__add_default (/home/acme/bin/perf)
cmd_record (/home/acme/bin/perf)
run_builtin (/home/acme/bin/perf)
handle_internal_command (/home/acme/bin/perf)
0.023 ( 0.004 ms): perf/4150 ... [continued]: perf_event_open()) = -1 EINVAL Invalid argument
0.028 ( 0.002 ms): perf/4150 perf_event_open(attr_uptr: 0x7ffebc8ba110, cpu: -1, group_fd: -1 ) ...
0.030 ( ): probe:x86_pmu_hw_config:(ffffffff9c0065e1))
x86_pmu_hw_config ([kernel.kallsyms])
hsw_hw_config ([kernel.kallsyms])
x86_pmu_event_init ([kernel.kallsyms])
perf_try_init_event ([kernel.kallsyms])
perf_event_alloc ([kernel.kallsyms])
SYSC_perf_event_open ([kernel.kallsyms])
sys_perf_event_open ([kernel.kallsyms])
do_syscall_64 ([kernel.kallsyms])
return_from_SYSCALL_64 ([kernel.kallsyms])
syscall (/usr/lib64/libc-2.24.so)
perf_event_attr__set_max_precise_ip (/home/acme/bin/perf)
perf_evsel__new_cycles (/home/acme/bin/perf)
perf_evlist__add_default (/home/acme/bin/perf)
cmd_record (/home/acme/bin/perf)
run_builtin (/home/acme/bin/perf)
handle_internal_command (/home/acme/bin/perf)
0.028 ( 0.004 ms): perf/4150 ... [continued]: perf_event_open()) = -1 EINVAL Invalid argument
41.018 ( 0.012 ms): perf/4150 perf_event_open(attr_uptr: 0x7ffebc8b5dd0, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
41.065 ( 0.011 ms): perf/4150 perf_event_open(attr_uptr: 0x3c7db78, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
41.080 ( 0.006 ms): perf/4150 perf_event_open(attr_uptr: 0x3c7db78, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
41.103 ( 0.010 ms): perf/4150 perf_event_open(attr_uptr: 0x3c4e748, pid: 4151 (perf), group_fd: -1, flags: FD_CLOEXEC) = 4
41.115 ( 0.006 ms): perf/4150 perf_event_open(attr_uptr: 0x3c4e748, pid: 4151 (perf), cpu: 1, group_fd: -1, flags: FD_CLOEXEC) = 5
41.122 ( 0.004 ms): perf/4150 perf_event_open(attr_uptr: 0x3c4e748, pid: 4151 (perf), cpu: 2, group_fd: -1, flags: FD_CLOEXEC) = 6
41.128 ( 0.008 ms): perf/4150 perf_event_open(attr_uptr: 0x3c4e748, pid: 4151 (perf), cpu: 3, group_fd: -1, flags: FD_CLOEXEC) = 8
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.017 MB perf.data (2 samples) ]
#I.e. that return -EINVAL in x86_pmu_hw_config() is hit three times.
So fix it by just setting attr.sample_period
Now, after this patch:
# perf trace --max-stack=2 -e perf_event_open,probe:x86_pmu_hw_config* perf record usleep 1
[ perf record: Woken up 1 times to write data ]
0.000 ( 0.017 ms): perf/8469 perf_event_open(attr_uptr: 0x7ffe36c27d10, pid: -1, cpu: 3, group_fd: -1, flags: FD_CLOEXEC) = 4
syscall (/usr/lib64/libc-2.24.so)
perf_event_open_cloexec_flag (/home/acme/bin/perf)
0.050 ( 0.031 ms): perf/8469 perf_event_open(attr_uptr: 0x24ebb78, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
syscall (/usr/lib64/libc-2.24.so)
perf_evlist__config (/home/acme/bin/perf)
0.092 ( 0.040 ms): perf/8469 perf_event_open(attr_uptr: 0x24ebb78, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
syscall (/usr/lib64/libc-2.24.so)
perf_evlist__config (/home/acme/bin/perf)
0.143 ( 0.007 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, cpu: -1, group_fd: -1 ) = 4
syscall (/usr/lib64/libc-2.24.so)
perf_event_attr__set_max_precise_ip (/home/acme/bin/perf)
0.161 ( 0.007 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, pid: 8470 (perf), group_fd: -1, flags: FD_CLOEXEC) = 4
syscall (/usr/lib64/libc-2.24.so)
perf_evsel__open (/home/acme/bin/perf)
0.171 ( 0.005 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, pid: 8470 (perf), cpu: 1, group_fd: -1, flags: FD_CLOEXEC) = 5
syscall (/usr/lib64/libc-2.24.so)
perf_evsel__open (/home/acme/bin/perf)
0.180 ( 0.007 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, pid: 8470 (perf), cpu: 2, group_fd: -1, flags: FD_CLOEXEC) = 6
syscall (/usr/lib64/libc-2.24.so)
perf_evsel__open (/home/acme/bin/perf)
0.190 ( 0.005 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, pid: 8470 (perf), cpu: 3, group_fd: -1, flags: FD_CLOEXEC) = 8
syscall (/usr/lib64/libc-2.24.so)
perf_evsel__open (/home/acme/bin/perf)
[ perf record: Captured and wrote 0.017 MB perf.data (7 samples) ]
#The probe one called from perf_event_attr__set_max_precise_ip() works the first time, with attr.precise_ip = 3, wit hthe next ones being the per cpu ones for the cycles:ppp event.
And here is the text from a report and alternative proposed patch by Thomas-Mich Richter:
---
On s390 the counter and sampling facility do not support a precise IP skid level and sometimes returns EOPNOTSUPP when structure member precise_ip in struct perf_event_attr is not set to zero.
On s390 commnd 'perf record -- true' fails with error EOPNOTSUPP. This happens only when no events are specified on command line.
The functions called are
...
--> perf_evlist__add_default
--> perf_evsel__new_cycles
--> perf_event_attr__set_max_precise_ipThe last function determines the value of structure member precise_ip by invoking the perf_event_open() system call and checking the return code. The first successful open is the value for precise_ip.
However the value is determined without setting member sample_period and indicates no sampling.
On s390 the counter facility and sampling facility are different. The above procedure determines a precise_ip value of 3 using the counter facility. Later it uses the sampling facility with a value of 3 and fails with EOPNOTSUPP.
---
v2: Older compilers (e.g. gcc 4.4.7) don't support referencing members
of unnamed union members in the container struct initialization, so
move from:
struct perf_event_attr attr = {
...
.sample_period = 1,
};to right after it as:
struct perf_event_attr attr = {
...
};
attr.sample_period = 1;--- tools/perf/tests/task-exit.c | 2 +- tools/perf/util/evsel.c | 5 +++++ 2 files changed, 6 insertions(+), 1 deletion(-)
tools/perf/tests/task-exit.c +1 -1
@@ -83,7 +83,7 @@ int test__task_exit(int subtest __maybe_unused) evsel =perf_evlist__first (evlist); evsel->attr.task =1 ; - evsel->attr.sample_freq =0 ; + evsel->attr.sample_freq =1 ; evsel->attr.inherit =0 ; evsel->attr.watermark =0 ; evsel->attr.wakeup_events =1 ;
tools/perf/util/evsel.c +5 -0
@@ -273,6 +273,11 @@ struct perf_evsel *perf_evsel__new_cycles(void)struct perf_evsel *evsel;event_attr_init (&attr); +/* +* Unnamed union member, not supported as struct member named +* initializer in older compilers such as gcc 4.4.7 +*/ + attr.sample_period =1 ;perf_event_attr__set_max_precise_ip (&attr);
Signature · 1 line
2.9.4
Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event
Quoted 22 lines · Arnaldo Carvalho de Melo
tools/perf/tests/task-exit.c | 2 +- tools/perf/util/evsel.c | 5 +++++ 2 files changed, 6 insertions(+), 1 deletion(-)tools/perf/tests/task-exit.c +1
-1@@ -83,7 +83,7 @@ int test__task_exit(int subtest __maybe_unused) evsel =perf_evlist__first (evlist); evsel->attr.task =1 ; - evsel->attr.sample_freq =0 ; + evsel->attr.sample_freq =1 ; evsel->attr.inherit =0 ; evsel->attr.watermark =0 ; evsel->attr.wakeup_events =1 ;tools/perf/util/evsel.c +0
-0
tools/perf/util/evsel.c struct perf_evsel *perf_evsel__new_cycles(void) · line 282
Quoted 10 lines
tools/perf/util/evsel.c +5
-0@@ -273,6 +273,11 @@ struct perf_evsel *perf_evsel__new_cycles(void)struct perf_evsel *evsel;event_attr_init (&attr); +/* +* Unnamed union member, not supported as struct member named +* initializer in older compilers such as gcc 4.4.7 +*/ + attr.sample_period =1 ;perf_event_attr__set_max_precise_ip (&attr);
Hm, so this really broke perf for me on my main system - 'perf top' and 'perf report' only shows:
triton:~/tip> perf report --stdio
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
# To display the perf.data header info, please use --header/--header-only options. #
#
# Total Lost Samples: 0
#
# Samples: 921K of event 'cycles:ppp'
# Event count (approx.): 921045
#
# Overhead Command Shared Object Symbol
# ........ ......... ................ ....................
#
99.93% hackbench [kernel.vmlinux] [k] native_write_msr
0.07% perf [kernel.vmlinux] [k] native_write_msrthe bisection result is unambiguous:
7fd1d092b4337831d7ccbf3a74c07cb0b2089023 is the first bad commit
proper output would be:
...
#
# Total Lost Samples: 0
#
# Samples: 9K of event 'cycles'
# Event count (approx.): 4378583062
#
# Overhead Command Shared Object Symbol
# ........ ......... ................ .......................................
#
4.32% hackbench [kernel.vmlinux] [k] copy_user_enhanced_fast_string
4.02% hackbench [kernel.vmlinux] [k] unix_stream_read_generic
3.75% hackbench [kernel.vmlinux] [k] filemap_map_pages
3.06% hackbench [kernel.vmlinux] [k] __check_object_size
2.44% hackbench [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.32% hackbench [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
2.22% hackbench [kernel.vmlinux] [k] entry_SYSENTER_compat
1.90% hackbench [vdso] [.] __vdso_gettimeofday
1.80% hackbench [kernel.vmlinux] [k] _raw_spin_lock
1.80% hackbench [kernel.vmlinux] [k] skb_set_owner_w
1.67% hackbench [kernel.vmlinux] [k] kmem_cache_free
1.52% hackbench [kernel.vmlinux] [k] skb_release_data
1.48% hackbench [kernel.vmlinux] [k] common_file_perm
1.45% hackbench [kernel.vmlinux] [k] page_fault
1.45% hackbench [kernel.vmlinux] [k] cmpxchg_double_slab.isra.62
1.42% hackbench [kernel.vmlinux] [k] new_sync_read
1.36% hackbench [kernel.vmlinux] [k] __check_heap_objectHere's the hardware details:
# ========
# captured on: Wed Jun 14 07:34:42 2017
# hostname : triton
# os release : 4.10.0-23-generic
# perf version : 4.12.rc5.g9688eb
# arch : x86_64
# nrcpus online : 12
# nrcpus avail : 12
# cpudesc : Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz
# cpuid : GenuineIntel,6,62,4
# total memory : 65917012 kB
# cmdline : /home/mingo/bin/perf record /home/mingo/hackbench 10
# event : name = cycles:ppp, , size = 112, { sample_period, sample_freq } = 1, sample_type = IP|TID|TIME, disabled = 1, inherit = 1, mmap = 1, comm = 1, enable_on_exec = 1, task = 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_cbox_5 = 21, uncore_ha_0 = 8, uncore_imc_2 = 9, uncore_cbox_3 = 19, cstate_pkg = 25, breakpoint = 5, uncore_imc_0 = 11, uncore_ubox = 15, uncore
# HEADER_CACHE info available, use -I to display
# missing features: HEADER_TRACING_DATA HEADER_BRANCH_STACK HEADER_GROUP_DESC HEADER_AUXTRACE HEADER_STAT
# ========let me know if you need more info.
Btw., note that there's also this warning:
unwind: target platform=x86 is not supported
(but that's unrelated to this commit.)
Thanks,
Ingo
Arnaldo Carvalho de Melo
maintainerRe: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event
Em Wed, Jun 14, 2017 at 07:45:01AM +0200, Ingo Molnar escreveu:
Quoted 62 lines · Arnaldo Carvalho de Melo
Review struct perf_evsel *perf_evsel__new_cycles(void) · line 280
Quoted 10 lines
+++
b/tools/perf/util/evsel.c(quoted diff) +5
-0@@ -273,6 +273,11 @@ struct perf_evsel *perf_evsel__new_cycles(void) event_attr_init(&attr); + /* + * Unnamed union member, not supported as struct member named + * initializer in older compilers such as gcc 4.4.7 + */ + attr.sample_period = 1; perf_event_attr__set_max_precise_ip(&attr);Hm, so this really broke perf for me on my main system - 'perf top' and 'perf report' only shows:
triton:~/tip> perf report --stdio
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
# To display the perf.data header info, please use --header/--header-only options. # Total Lost Samples: 0# Samples: 921K of event 'cycles:ppp'
# Event count (approx.): 921045# Overhead Command Shared Object Symbol # ........ ......... ................ .................... 99.93% hackbench [kernel.vmlinux] [k] native_write_msr 0.07% perf [kernel.vmlinux] [k] native_write_msrthe bisection result is unambiguous:
7fd1d092b4337831d7ccbf3a74c07cb0b2089023is the first bad commitproper output would be:
...
# Total Lost Samples: 0
#
# Samples: 9K of event 'cycles'
# Event count (approx.): 4378583062
## Overhead Command Shared Object Symbol # ........ ......... ................ ....................................... 4.32% hackbench [kernel.vmlinux] [k] copy_user_enhanced_fast_string 4.02% hackbench [kernel.vmlinux] [k] unix_stream_read_generic 3.75% hackbench [kernel.vmlinux] [k] filemap_map_pages 3.06% hackbench [kernel.vmlinux] [k] __check_object_size 2.44% hackbench [kernel.vmlinux] [k] _raw_spin_lock_irqsave 2.32% hackbench [kernel.vmlinux] [k] native_queued_spin_lock_slowpath 2.22% hackbench [kernel.vmlinux] [k] entry_SYSENTER_compat 1.90% hackbench [vdso] [.] __vdso_gettimeofday 1.80% hackbench [kernel.vmlinux] [k] _raw_spin_lock 1.80% hackbench [kernel.vmlinux] [k] skb_set_owner_w 1.67% hackbench [kernel.vmlinux] [k] kmem_cache_free 1.52% hackbench [kernel.vmlinux] [k] skb_release_data 1.48% hackbench [kernel.vmlinux] [k] common_file_perm 1.45% hackbench [kernel.vmlinux] [k] page_fault 1.45% hackbench [kernel.vmlinux] [k] cmpxchg_double_slab.isra.62 1.42% hackbench [kernel.vmlinux] [k] new_sync_read 1.36% hackbench [kernel.vmlinux] [k] __check_heap_object
Quoted 1 line
Here's the hardware details:
No need for that, its simpler, brown paper bag, I concentrated on it not returning -EINVAL and didn't test it enough, ditto with the other guys that tested this on s/390 :-\
The default case gets the precise_ip right, i.e. 3 in this broadwell machine, but remained with the sample_period=1 used to probe it, ugh.
[root@jouet ~]# perf record usleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.021 MB perf.data (69 samples) ]
[root@jouet ~]# perf evlist -v
cycles:ppp: size: 112, { sample_period, sample_freq }: 1, sample_type: IP|TID|TIME, disabled: 1, inherit: 1, mmap: 1, comm: 1, enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1
If we use 'cycles:P' explicitely we can see that it uses the default sample_freq:
[root@jouet ~]# perf record -e cycles:P usleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.018 MB perf.data (8 samples) ]
[root@jouet ~]# perf evlist -v
cycles:P: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, mmap2: 1, comm_exec: 1 [root@jouet ~]#
Can you try with the patch below, which is hackish but the minimal fix at this point. Later I'll come up with a way of returning a fully configured cycles evsel, which will make the tools code simpler, moving more stuff to the libraries.
I'll look into the unwind case, where SRCARCH is being passed to the unwind code uses both x86_64, not x86 (probably uses i386 or x86_32 for the 32-bit case).
- Arnaldo
tools/perf/util/evsel.c +7 -0
@@ -276,10 +276,17 @@ struct perf_evsel *perf_evsel__new_cycles(void)/* * Unnamed union member, not supported as struct member named * initializer in older compilers such as gcc 4.4.7 +* +* Just for probing the precise_ip: */ attr.sample_period =1 ;perf_event_attr__set_max_precise_ip (&attr); +/* +* Now let the usual logic to set up the perf_event_attr defaults +* to kick in when we return and before perf_evsel__open() is called. +*/ + attr.sample_period =0 ; evsel =perf_evsel__new (&attr);if (evsel ==NULL )
Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event
Quoted 4 lines · Arnaldo Carvalho de Melo
Can you try with the patch below, which is hackish but the minimal fix at this point. Later I'll come up with a way of returning a fully configured cycles evsel, which will make the tools code simpler, moving more stuff to the libraries.
Yeah, this patch on top of your tree seems to work better now.
Thanks,
Ingo
Arnaldo Carvalho de Melo
maintainerRe: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event
Em Wed, Jun 14, 2017 at 12:51:55PM +0200, Ingo Molnar escreveu:
Quoted 9 lines · Arnaldo Carvalho de Melo
Quoted 5 lines
Can you try with the patch below, which is hackish but the minimal fix at this point. Later I'll come up with a way of returning a fully configured cycles evsel, which will make the tools code simpler, moving more stuff to the libraries.
Yeah, this patch on top of your tree seems to work better now.
So how do we proceed, do you want to keep these two as separate or can I squash them together, fix that problem with the unwind library and provide a new perf/urgent for you to use?
Off to breakfast now tho :-)
- Arnaldo
Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event
Quoted 9 lines · Arnaldo Carvalho de Melo
Em Wed, Jun 14, 2017 at 12:51:55PM +0200, Ingo Molnar escreveu:
Quoted 8 lines · Arnaldo Carvalho de Melo
Quoted 5 lines
Can you try with the patch below, which is hackish but the minimal fix at this point. Later I'll come up with a way of returning a fully configured cycles evsel, which will make the tools code simpler, moving more stuff to the libraries.
Quoted 7 lines
Quoted 1 line
Yeah, this patch on top of your tree seems to work better now.
So how do we proceed, do you want to keep these two as separate or can I squash them together, fix that problem with the unwind library and provide a new perf/urgent for you to use?
Off to breakfast now tho :-)
Your call: I had to unpull, so feel free to rebase your urgent branch.
Thanks,
Ingo
Arnaldo Carvalho de Melo
maintainerRe: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event
Em Wed, Jun 14, 2017 at 03:55:22PM +0200, Ingo Molnar escreveu:
Quoted 14 lines · Arnaldo Carvalho de Melo
Quoted 12 lines
Em Wed, Jun 14, 2017 at 12:51:55PM +0200, Ingo Molnar escreveu:
Quoted 9 lines · Arnaldo Carvalho de Melo
Quoted 5 lines
Can you try with the patch below, which is hackish but the minimal fix at this point. Later I'll come up with a way of returning a fully configured cycles evsel, which will make the tools code simpler, moving more stuff to the libraries.
Yeah, this patch on top of your tree seems to work better now.
Quoted 7 lines
Quoted 5 lines
So how do we proceed, do you want to keep these two as separate or can I squash them together, fix that problem with the unwind library and provide a new perf/urgent for you to use?
Off to breakfast now tho :-)
Your call: I had to unpull, so feel free to rebase your urgent branch.
Ok, I'll rebase it, prepare another pull req after we nail down the unwind one.
- Arnaldo
Arnaldo Carvalho de Melo
maintainerRe: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event
In reply to Ingo MolnarEm Wed, Jun 14, 2017 at 07:45:01AM +0200, Ingo Molnar escreveu:
Quoted 23 lines
triton:~/tip> perf report --stdio
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported# ========
# captured on: Wed Jun 14 07:34:42 2017 # hostname : triton # os release : 4.10.0-23-generic # perf version : 4.12.rc5.g9688eb # arch : x86_64 # nrcpus online : 12 # nrcpus avail : 12 # cpudesc : Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz # cpuid : GenuineIntel,6,62,4 # total memory : 65917012 kB # cmdline : /home/mingo/bin/perf record /home/mingo/hackbench 10
Quoted 7 lines
let me know if you need more info.
Btw., note that there's also this warning:
unwind: target platform=x86 is not supported
(but that's unrelated to this commit.)
Ok, what distro? Do you have libunwind-devel installed? I couldn't reproduce this one here with/without it installed, to test I build it with:
make ARCH=x86_64 O=/tmp/build/perf -C tools/perf install-bin
and without that ARCH= setting, then I record with:
perf record --call-graph dwarf -a sleep 2
and try what you said emitted that warning:
perf report --stdio
- Arnaldo
Arnaldo Carvalho de Melo
maintainerperf: unwind: target platform=x86 not supported was: Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event
Em Wed, Jun 14, 2017 at 10:29:47AM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 38 lines
Em Wed, Jun 14, 2017 at 07:45:01AM +0200, Ingo Molnar escreveu:
Quoted 23 lines
triton:~/tip> perf report --stdio
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported# ========
# captured on: Wed Jun 14 07:34:42 2017 # hostname : triton # os release : 4.10.0-23-generic # perf version : 4.12.rc5.g9688eb # arch : x86_64 # nrcpus online : 12 # nrcpus avail : 12 # cpudesc : Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz # cpuid : GenuineIntel,6,62,4 # total memory : 65917012 kB # cmdline : /home/mingo/bin/perf record /home/mingo/hackbench 10Quoted 7 lines
let me know if you need more info.
Btw., note that there's also this warning:
unwind: target platform=x86 is not supported
(but that's unrelated to this commit.)
Ok, what distro? Do you have libunwind-devel installed? I couldn't reproduce this one here with/without it installed, to test I build it with:
make ARCH=x86_64 O=/tmp/build/perf -C
tools/perfinstall-bin
Quoted 7 lines
and without that ARCH= setting, then I record with:
perf record --call-graph dwarf -a sleep 2and try what you said emitted that warning:
perf report --stdio
So, the "unwind: target platform=x86 is not supported" comes only from:
a tools/perf/util/unwind-libunwind.c
That is linked by:
$ grep libunwind-local tools/perf/util/Build libperf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind-local.o $
And here CONFIG_LOCAL_LIBUNWIND is detected:
[acme@jouet linux]$ grep CONFIG_LOCAL_LIBUNWIND /tmp/build/perf/.config-detected CONFIG_LOCAL_LIBUNWIND=y
[acme@jouet linux]$
And that message is there:
[acme@jouet linux]$ strings ~/bin/perf | grep "unwind: target platform="
unwind: target platform=%s is not supported
[acme@jouet linux]$
So the only way for get to that point would be for local_unwind_libunwind_ops to be NULL, which it will be if its __weak definition seting it to zero isn't overriden by...
tools/perf/util/unwind-libunwind-local.c
#ifndef REMOTE_UNWIND_LIBUNWIND
struct unwind_libunwind_ops * local_unwind_libunwind_ops = &_unwind_libunwind_ops; #endif
And what defines it is...
tools/perf/util/libunwind/x86_32.c:#define REMOTE_UNWIND_LIBUNWIND
(and a arm64 file, but lets leave that aside, seems unrelated to this case)
That will get built by...
tools/perf/util/Build:libperf-$(CONFIG_LIBUNWIND_X86) += libunwind/x86_32.o
[acme@jouet linux]$ grep CONFIG_LIBUNWIND_X86 /tmp/build/perf/.config-detected [acme@jouet linux]$
Ingo, are you doing something unusual as building a 32-bit perf to read a 62-bit perf.data file?
Jiri, can you help here? Do you need more info?
- Arnaldo
Re: perf: unwind: target platform=x86 not supported was: Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event
On Wed, Jun 14, 2017 at 10:52:42AM -0300, Arnaldo Carvalho de Melo wrote:
SNIP
Quoted 12 lines
And what defines it is...
tools/perf/util/libunwind/x86_32.c:#define
REMOTE_UNWIND_LIBUNWIND(and a arm64 file, but lets leave that aside, seems unrelated to this case)
That will get built by...
tools/perf/util/Build:libperf-$(CONFIG_LIBUNWIND_X86) +=
libunwind/x86_32.o
Quoted 7 lines
[acme@jouet linux]$ grep
CONFIG_LIBUNWIND_X86/tmp/build/perf/.config-detected[acme@jouet linux]$Ingo, are you doing something unusual as building a 32-bit perf to read a 62-bit perf.data file?
Jiri, can you help here? Do you need more info?
hum, looks like local unwind support wasn't compiled in for some reason
Ingo, what's the arch of host and perf data?
thanks,
jirka
Re: perf: unwind: target platform=x86 not supported was: Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event
Quoted 19 lines · Jiri Olsa
On Wed, Jun 14, 2017 at 10:52:42AM -0300, Arnaldo Carvalho de Melo wrote:
SNIP
Quoted 15 lines
And what defines it is...
tools/perf/util/libunwind/x86_32.c:#define
REMOTE_UNWIND_LIBUNWIND(and a arm64 file, but lets leave that aside, seems unrelated to this case)
That will get built by...
tools/perf/util/Build:libperf-$(CONFIG_LIBUNWIND_X86) +=
libunwind/x86_32.o[acme@jouet linux]$ grep
CONFIG_LIBUNWIND_X86/tmp/build/perf/.config-detected[acme@jouet linux]$
Quoted 8 lines
Quoted 4 lines
Ingo, are you doing something unusual as building a 32-bit perf to read a 62-bit perf.data file?
Jiri, can you help here? Do you need more info?
hum, looks like local unwind support wasn't compiled in for some reason
Ingo, what's the arch of host and perf data?
also "make clean && make VF=1 V=1" output would help
thanks,
jirka
Arnaldo Carvalho de Melo
maintainerRe: perf: unwind: target platform=x86 not supported was: Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event
In reply to Jiri OlsaEm Wed, Jun 14, 2017 at 04:19:51PM +0200, Jiri Olsa escreveu:
Quoted 19 lines · Arnaldo Carvalho de Melo
SNIP
Quoted 15 lines
And what defines it is...
tools/perf/util/libunwind/x86_32.c:#define
REMOTE_UNWIND_LIBUNWIND(and a arm64 file, but lets leave that aside, seems unrelated to this case)
That will get built by...
tools/perf/util/Build:libperf-$(CONFIG_LIBUNWIND_X86) +=
libunwind/x86_32.o[acme@jouet linux]$ grep
CONFIG_LIBUNWIND_X86/tmp/build/perf/.config-detected[acme@jouet linux]$
Quoted 8 lines
Quoted 4 lines
Ingo, are you doing something unusual as building a 32-bit perf to read a 62-bit perf.data file?
Jiri, can you help here? Do you need more info?
hum, looks like local unwind support wasn't compiled in for some reason
Ingo, what's the arch of host and perf data?
amd64/x86_64, ubuntu, libunwind version 8, perhaps this version has a problem? See the other message I replied to Ingo, added you to the CC.
- Arnaldo
Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event
In reply to Arnaldo Carvalho de MeloQuoted 26 lines · Arnaldo Carvalho de Melo
Em Wed, Jun 14, 2017 at 07:45:01AM +0200, Ingo Molnar escreveu:
Quoted 25 lines
triton:~/tip> perf report --stdio
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported# ========
# captured on: Wed Jun 14 07:34:42 2017 # hostname : triton # os release : 4.10.0-23-generic # perf version : 4.12.rc5.g9688eb # arch : x86_64 # nrcpus online : 12 # nrcpus avail : 12 # cpudesc : Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz # cpuid : GenuineIntel,6,62,4 # total memory : 65917012 kB # cmdline : /home/mingo/bin/perf record /home/mingo/hackbench 10let me know if you need more info.
Quoted 7 lines
Quoted 5 lines
Btw., note that there's also this warning:
unwind: target platform=x86 is not supported
(but that's unrelated to this commit.)
Ok, what distro? Do you have libunwind-devel installed? [...]
Ubuntu, and the build says:
Auto-detecting system features:
... dwarf: [ on ] ... dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libaudit: [ on ] ... libbfd: [ on ] ... libelf: [ on ] ... libnuma: [ on ] ... numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ... libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ]
so it's a maximum-features build, right?
Here's the unwind libraries:
triton:~/tip> dpkg -l | grep unwind
ii libunwind-dev 1.1-4.1ubuntu2 amd64 library to determine the call-chain of a program - development ii libunwind8 1.1-4.1ubuntu2 amd64 library to determine the call-chain of a program - runtime ii libunwind8-dev 1.1-4.1ubuntu2 amd64 library to determine the call-chain of a program - development
libunwind-dev is installed it appears.
Let me know if you want me to run other tests.
Thanks,
Ingo
Arnaldo Carvalho de Melo
maintainerRe: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event
Em Wed, Jun 14, 2017 at 04:06:01PM +0200, Ingo Molnar escreveu:
Quoted 60 lines · Arnaldo Carvalho de Melo
Quoted 27 lines
Em Wed, Jun 14, 2017 at 07:45:01AM +0200, Ingo Molnar escreveu:
Quoted 25 lines
triton:~/tip> perf report --stdio
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported# ========
# captured on: Wed Jun 14 07:34:42 2017 # hostname : triton # os release : 4.10.0-23-generic # perf version : 4.12.rc5.g9688eb # arch : x86_64 # nrcpus online : 12 # nrcpus avail : 12 # cpudesc : Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz # cpuid : GenuineIntel,6,62,4 # total memory : 65917012 kB # cmdline : /home/mingo/bin/perf record /home/mingo/hackbench 10let me know if you need more info.
Quoted 7 lines
Quoted 5 lines
Btw., note that there's also this warning:
unwind: target platform=x86 is not supported
(but that's unrelated to this commit.)
Ok, what distro? Do you have libunwind-devel installed? [...]
Ubuntu, and the build says:
Auto-detecting system features:
... dwarf: [ on ] ... dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libaudit: [ on ] ... libbfd: [ on ] ... libelf: [ on ] ... libnuma: [ on ] ... numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ... libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ]
Quoted 8 lines
so it's a maximum-features build, right?
Here's the unwind libraries:
triton:~/tip> dpkg -l | grep unwind
ii libunwind-dev 1.1-4.1ubuntu2 amd64 library to determine the call-chain of a program - development ii libunwind8 1.1-4.1ubuntu2 amd64 library to determine the call-chain of a program - runtime ii libunwind8-dev 1.1-4.1ubuntu2 amd64 library to determine the call-chain of a program - development
Ok, but it is libunwind version 8, so this should narrow down the problem, probably this one doesn't have that REMOTE_UNWIND_LIBUNWIND somewhow, Jiri?
- Arnaldo
Quoted 8 lines
libunwind-dev is installed it appears.
Let me know if you want me to run other tests.
Thanks,
Ingo
Arnaldo Carvalho de Melo
maintainerRe: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event
In reply to Ingo MolnarEm Wed, Jun 14, 2017 at 04:06:01PM +0200, Ingo Molnar escreveu:
Quoted 6 lines · Arnaldo Carvalho de Melo
Quoted 3 lines
Em Wed, Jun 14, 2017 at 07:45:01AM +0200, Ingo Molnar escreveu:
Quoted 2 lines
triton:~/tip> perf report --stdio
unwind: target platform=x86 is not supportedso it's a maximum-features build, right?
looks like
Quoted 10 lines
Here's the unwind libraries:
triton:~/tip> dpkg -l | grep unwind
ii libunwind-dev 1.1-4.1ubuntu2 amd64 library to determine the call-chain of a program - development ii libunwind8 1.1-4.1ubuntu2 amd64 library to determine the call-chain of a program - runtime ii libunwind8-dev 1.1-4.1ubuntu2 amd64 library to determine the call-chain of a program - developmentlibunwind-dev is installed it appears.
Let me know if you want me to run other tests.
Couldn't reproduce so far :-\ I am trying it on a docker container with Ubuntu 16.04, is that the version you're using, seems to be the 16.04, at least the packages above listed are the same as in my container...
Also it would be nice to see if this is something introduced by Jiada's patch:
Author: Jiada Wang <[email protected]> Date: Sun Apr 9 20:02:37 2017 -0700
perf tools: Fix build with ARCH=x86_64
---------------------------
I.e. the other patch in my perf/urgent branch, does this warning go away if you apply just the first patch in my perf/urgent branch as of now?
Here is my testing:
root@5754d7c06d56:/# perf record -F 10000 --call-graph dwarf sleep 5
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.118 MB perf.data (14 samples) ]
root@5754d7c06d56:/# perf report --stdio --dsos '[kernel.kallsyms]' 2>&1 | head -20
# To display the perf.data header info, please use --header/--header-only options.
#
# dso: [kernel.kallsyms]
#
# Total Lost Samples: 0
#
# Samples: 14 of event 'cycles:ppp'
# Event count (approx.): 1085705
#
# Children Self Command Symbol
# ........ ........ ....... ..............................
#
28.16% 0.00% sleep [k] page_fault
|
---page_fault
do_page_fault
__do_page_fault
handle_mm_fault
|
|--17.82%--__handle_mm_fault
root@5754d7c06d56:/# grep Ubuntu /etc/os-release
NAME="Ubuntu"
PRETTY_NAME="Ubuntu 16.04.2 LTS"
root@5754d7c06d56:/#- Arnaldo
- Arnaldo
Arnaldo Carvalho de Melo
maintainerPATCH 2/2 perf tools: Fix build with ARCH=x86_64
In reply to Arnaldo Carvalho de MeloFrom: Jiada Wang <[email protected]>
With commit: 0a943cb10ce78 (tools build: Add HOSTARCH Makefile variable) when building for ARCH=x86_64, ARCH=x86_64 is passed to perf instead of ARCH=x86, so the perf build process searchs header files from tools/arch/x86_64/include, which doesn't exist.
The following build failure is seen:
In file included from util/event.c:2:0:
tools/include/uapi/linux/mman.h:4:27: fatal error: uapi/asm/mman.h: No such file or directory compilation terminated.
Fix this issue by using SRCARCH instead of ARCH in perf, just like the main kernel Makefile and tools/objtool's.
--- tools/perf/Makefile.config | 38 +++++++++++++++++++------------------- tools/perf/Makefile.perf | 2 +- tools/perf/arch/Build | 2 +- tools/perf/pmu-events/Build | 4 ++-- tools/perf/tests/Build | 2 +- tools/perf/util/header.c | 2 +- 6 files changed, 25 insertions(+), 25 deletions(-)
tools/perf/Makefile.config +19 -19
@@ -19,18 +19,18 @@ CFLAGS := $(EXTRA_CFLAGS) $(EXTRA_WARNINGS) include $(srctree)/tools/scripts/Makefile.arch -$(call detected_var,ARCH) +$(call detected_var,SRCARCH) NO_PERF_REGS := 1 # Additional ARCH settings for ppc -ifeq ($(ARCH),powerpc) +ifeq ($(SRCARCH),powerpc) NO_PERF_REGS := 0 LIBUNWIND_LIBS := -lunwind -lunwind-ppc64 endif # Additional ARCH settings for x86 -ifeq ($(ARCH),x86) +ifeq ($(SRCARCH),x86) $(call detected,CONFIG_X86) ifeq (${IS_64_BIT}, 1) CFLAGS += -DHAVE_ARCH_X86_64_SUPPORT -DHAVE_SYSCALL_TABLE -I$(OUTPUT)arch/x86/include/generated
@@ -43,12 +43,12 @@ ifeq ($(ARCH),x86) NO_PERF_REGS := 0 endif -ifeq ($(ARCH),arm) +ifeq ($(SRCARCH),arm) NO_PERF_REGS := 0 LIBUNWIND_LIBS = -lunwind -lunwind-arm endif -ifeq ($(ARCH),arm64) +ifeq ($(SRCARCH),arm64) NO_PERF_REGS := 0 LIBUNWIND_LIBS = -lunwind -lunwind-aarch64 endif
@@ -61,7 +61,7 @@ endif # Disable it on all other architectures in case libdw unwind # support is detected in system. Add supported architectures # to the check. -ifneq ($(ARCH),$(filter $(ARCH),x86 arm)) +ifneq ($(SRCARCH),$(filter $(SRCARCH),x86 arm)) NO_LIBDW_DWARF_UNWIND := 1 endif
@@ -115,9 +115,9 @@ endif FEATURE_CHECK_CFLAGS-libbabeltrace := $(LIBBABELTRACE_CFLAGS) FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS) -lbabeltrace-ctf -FEATURE_CHECK_CFLAGS-bpf = -I. -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(ARCH)/include/uapi -I$(srctree)/tools/include/uapi +FEATURE_CHECK_CFLAGS-bpf = -I. -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(SRCARCH)/include/uapi -I$(srctree)/tools/include/uapi # include ARCH specific config --include $(src-perf)/arch/$(ARCH)/Makefile +-include $(src-perf)/arch/$(SRCARCH)/Makefile ifdef PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET CFLAGS += -DHAVE_ARCH_REGS_QUERY_REGISTER_OFFSET
@@ -228,12 +228,12 @@ ifeq ($(DEBUG),0) endif INC_FLAGS += -I$(src-perf)/util/include -INC_FLAGS += -I$(src-perf)/arch/$(ARCH)/include +INC_FLAGS += -I$(src-perf)/arch/$(SRCARCH)/include INC_FLAGS += -I$(srctree)/tools/include/uapi INC_FLAGS += -I$(srctree)/tools/include/ -INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/uapi -INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/ -INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/ +INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/include/uapi +INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/include/ +INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/ # $(obj-perf) for generated common-cmds.h # $(obj-perf)/util for generated bison/flex headers
@@ -355,7 +355,7 @@ ifndef NO_LIBELF ifndef NO_DWARF ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined) - msg := $(warning DWARF register mappings have not been defined for architecture $(ARCH), DWARF support disabled); + msg := $(warning DWARF register mappings have not been defined for architecture $(SRCARCH), DWARF support disabled); NO_DWARF := 1 else CFLAGS += -DHAVE_DWARF_SUPPORT $(LIBDW_CFLAGS)
@@ -380,7 +380,7 @@ ifndef NO_LIBELF CFLAGS += -DHAVE_BPF_PROLOGUE $(call detected,CONFIG_BPF_PROLOGUE) else - msg := $(warning BPF prologue is not supported by architecture $(ARCH), missing regs_query_register_offset()); + msg := $(warning BPF prologue is not supported by architecture $(SRCARCH), missing regs_query_register_offset()); endif else msg := $(warning DWARF support is off, BPF prologue is disabled);
@@ -406,7 +406,7 @@ ifdef PERF_HAVE_JITDUMP endif endif -ifeq ($(ARCH),powerpc) +ifeq ($(SRCARCH),powerpc) ifndef NO_DWARF CFLAGS += -DHAVE_SKIP_CALLCHAIN_IDX endif
@@ -487,7 +487,7 @@ else endif ifndef NO_LOCAL_LIBUNWIND - ifeq ($(ARCH),$(filter $(ARCH),arm arm64)) + ifeq ($(SRCARCH),$(filter $(SRCARCH),arm arm64)) $(call feature_check,libunwind-debug-frame) ifneq ($(feature-libunwind-debug-frame), 1) msg := $(warning No debug_frame support found in libunwind);
@@ -740,7 +740,7 @@ ifeq (${IS_64_BIT}, 1) NO_PERF_READ_VDSO32 := 1 endif endif - ifneq ($(ARCH), x86) + ifneq ($(SRCARCH), x86) NO_PERF_READ_VDSOX32 := 1 endif ifndef NO_PERF_READ_VDSOX32
@@ -769,7 +769,7 @@ ifdef LIBBABELTRACE endif ifndef NO_AUXTRACE - ifeq ($(ARCH),x86) + ifeq ($(SRCARCH),x86) ifeq ($(feature-get_cpuid), 0) msg := $(warning Your gcc lacks the __get_cpuid() builtin, disables support for auxtrace/Intel PT, please install a newer gcc); NO_AUXTRACE := 1
@@ -872,7 +872,7 @@ sysconfdir = $(prefix)/etc ETC_PERFCONFIG = etc/perfconfig endif ifndef lib -ifeq ($(ARCH)$(IS_64_BIT), x861) +ifeq ($(SRCARCH)$(IS_64_BIT), x861) lib = lib64 else lib = lib
tools/perf/Makefile.perf +1 -1
@@ -226,7 +226,7 @@ endif ifeq ($(config),0) include $(srctree)/tools/scripts/Makefile.arch --include arch/$(ARCH)/Makefile +-include arch/$(SRCARCH)/Makefile endif # The FEATURE_DUMP_EXPORT holds location of the actual
tools/perf/arch/Build +1 -1
@@ -1,2 +1,2 @@ libperf-y += common.o -libperf-y += $(ARCH)/ +libperf-y += $(SRCARCH)/
tools/perf/pmu-events/Build +2 -2
@@ -2,7 +2,7 @@ hostprogs := jevents jevents-y += json.o jsmn.o jevents.o pmu-events-y += pmu-events.o -JDIR = pmu-events/arch/$(ARCH) +JDIR = pmu-events/arch/$(SRCARCH) JSON = $(shell [ -d $(JDIR) ] && \ find $(JDIR) -name '*.json' -o -name 'mapfile.csv') #
@@ -10,4 +10,4 @@ JSON = $(shell [ -d $(JDIR) ] && \ # directory and create tables in pmu-events.c. # $(OUTPUT)pmu-events/pmu-events.c: $(JSON) $(JEVENTS) - $(Q)$(call echo-cmd,gen)$(JEVENTS) $(ARCH) pmu-events/arch $(OUTPUT)pmu-events/pmu-events.c $(V) + $(Q)$(call echo-cmd,gen)$(JEVENTS) $(SRCARCH) pmu-events/arch $(OUTPUT)pmu-events/pmu-events.c $(V)
tools/perf/tests/Build +1 -1
@@ -75,7 +75,7 @@ $(OUTPUT)tests/llvm-src-relocation.c: tests/bpf-script-test-relocation.c tests/B $(Q)sed -e 's/"/\\"/g' -e 's/\(.*\)/"\1\\n"/g' $< >> $@ $(Q)echo ';' >> $@ -ifeq ($(ARCH),$(filter $(ARCH),x86 arm arm64 powerpc)) +ifeq ($(SRCARCH),$(filter $(SRCARCH),x86 arm arm64 powerpc)) perf-$(CONFIG_DWARF_UNWIND) += dwarf-unwind.o endif
tools/perf/util/header.c +1 -1
@@ -841,7 +841,7 @@ static int write_group_desc(int fd, struct perf_header *h __maybe_unused,/* * default get_cpuid(): nothing gets recorded -* actual implementation must be in arch/$(ARCH)/util/header.c +* actual implementation must be in arch/$(SRCARCH)/util/header.c */ int __weak get_cpuid (char *buffer__maybe_unused ,size_t sz__maybe_unused ) {
Signature · 1 line
2.9.4
Quoted 64 lines · Arnaldo Carvalho de Melo
Hi Ingo,
Please consider pulling,
- Arnaldo
Test results at the end of this message, as usual.
The following changes since commit
47c1ded7fef108c730b803cd386241beffcdd15c:Merge tag 'perf-urgent-for-mingo-4.12-20170608' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linuxinto perf/urgent (2017-06-09 00:41:33 +0200)are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.gittags/perf-urgent-for-mingo-4.12-20170613for you to fetch changes up to
9e0c6fd15fcaea39784d1fb3e9fc573f1cf0ae60:perf tools: Fix build with ARCH=x86_64 (2017-06-13 16:20:37 -0300)
----------------------------------------------------------------
perf/urgent fixes:- Fix probing of
precise_iplevel for default cycles event, that got broken recently onx86_64when its arch code started considering invalid requesting precise samples when not sampling (i.e. when attr.sample_period == 0).This also fixes another problem in s/390 where the precision probing with
sample_period== 0 returnedprecise_ip> 0, that then, when setting up the real cycles event (not probing) would return EOPNOTSUPP forprecise_ip> 0 (as determined previously by probing) andsample_period> 0.These problems resulted in
attr_precisenot being set to the highest precision available on x86.64 when no event was specified, i.e. the canonical:perf record ./workload
would end up using attr.precise_ip = 0. As a workaround this would need to be done:
perf record -e cycles:P ./workload
And on s/390 it would plain not work, requiring using:
perf record -e cycles ./workload
as a workaround. (Arnaldo Carvalho de Melo)
- Fix perf build with ARCH=x86_64, when ARCH should be transformed into ARCH=x86, just like with the main kernel
Makefileand tools/objtool's, i.e. use SRCARCH. (Jiada Wang)Signed-off-by Arnaldo Carvalho de Melo <[email protected]>----------------------------------------------------------------
Arnaldo Carvalho de Melo (1):
perf evsel: Fix probing ofprecise_iplevel for default cycles eventJiada Wang (1):
perf tools: Fix build with ARCH=x86_64
Quoted 9 lines
tools/perf/Makefile.config | 38 +++++++++++++++++++------------------- tools/perf/Makefile.perf | 2 +- tools/perf/arch/Build | 2 +- tools/perf/pmu-events/Build | 4 ++-- tools/perf/tests/Build | 2 +- tools/perf/tests/task-exit.c | 2 +- tools/perf/util/evsel.c | 5 +++++ tools/perf/util/header.c | 2 +- 8 files changed, 31 insertions(+), 26 deletions(-)
Pulled, thanks a lot Arnaldo!
Ingo