- 18 6月, 2019 15 次提交
-
-
由 Arnaldo Carvalho de Melo 提交于
We were just skipping the syscalls not available in a particular architecture without reflecting this in the number of entries in the ev_qualifier_ids.nr variable, fix it. This was done with the most minimalistic way, reusing the index variable 'i', a followup patch will further clean this by making 'i' renamed to 'nr_used' and using 'nr_allocated' in a few more places. Reported-by: NLeo Yan <leo.yan@linaro.org> Tested-by: NLeo Yan <leo.yan@linaro.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Mike Leach <mike.leach@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Fixes: 04c41bcb ("perf trace: Skip unknown syscalls when expanding strace like syscall groups") Link: https://lkml.kernel.org/r/20190613181514.GC1402@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Arnaldo Carvalho de Melo 提交于
Laura reported that the perf build failed in fedora when we got a glibc that provides gettid(), which I reproduced using fedora rawhide with the glibc-devel-2.29.9000-26.fc31.x86_64 package. Add a feature check to avoid providing a gettid() helper in such systems. On a fedora rawhide system with this patch applied we now get: [root@7a5f55352234 perf]# grep gettid /tmp/build/perf/FEATURE-DUMP feature-gettid=1 [root@7a5f55352234 perf]# cat /tmp/build/perf/feature/test-gettid.make.output [root@7a5f55352234 perf]# ldd /tmp/build/perf/feature/test-gettid.bin linux-vdso.so.1 (0x00007ffc6b1f6000) libc.so.6 => /lib64/libc.so.6 (0x00007f04e0a74000) /lib64/ld-linux-x86-64.so.2 (0x00007f04e0c47000) [root@7a5f55352234 perf]# nm /tmp/build/perf/feature/test-gettid.bin | grep -w gettid U gettid@@GLIBC_2.30 [root@7a5f55352234 perf]# While on a fedora:29 system: [acme@quaco perf]$ grep gettid /tmp/build/perf/FEATURE-DUMP feature-gettid=0 [acme@quaco perf]$ cat /tmp/build/perf/feature/test-gettid.make.output test-gettid.c: In function ‘main’: test-gettid.c:8:9: error: implicit declaration of function ‘gettid’; did you mean ‘getgid’? [-Werror=implicit-function-declaration] return gettid(); ^~~~~~ getgid cc1: all warnings being treated as errors [acme@quaco perf]$ Reported-by: NLaura Abbott <labbott@redhat.com> Tested-by: NLaura Abbott <labbott@redhat.com> Acked-by: NJiri Olsa <jolsa@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Florian Weimer <fweimer@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephane Eranian <eranian@google.com> Link: https://lkml.kernel.org/n/tip-yfy3ch53agmklwu9o7rlgf9c@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Like other synthesized events, if there is also an Intel PT branch trace, then a call stack can also be synthesized. Add that. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190610072803.10456-12-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Add memory information from PEBS data in the Intel PT trace to the synthesized PEBS sample. This provides sample types PERF_SAMPLE_ADDR, PERF_SAMPLE_WEIGHT, and PERF_SAMPLE_TRANSACTION, but not PERF_SAMPLE_DATA_SRC. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190610072803.10456-11-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Add LBR information from PEBS data in the Intel PT trace to the synthesized PEBS sample. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190610072803.10456-10-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Add XMM register information from PEBS data in the Intel PT trace to the synthesized PEBS sample. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190610072803.10456-9-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Add general purpose register information from PEBS data in the Intel PT trace to the synthesized PEBS sample. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190610072803.10456-8-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Synthesize a PEBS sample using basic information (ip, timestamp) only. Other PEBS information will be added in later patches. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190610072803.10456-7-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Factor out common sample preparation for re-use when synthesizing PEBS samples. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190610072803.10456-6-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Add infrastructure to prepare for synthesizing PEBS samples but leave the actual synthesis to later patches. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190610072803.10456-5-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
PEBS data is encoded in Block Item Packets (BIP). Populate a new structure intel_pt_blk_items with the values and, upon a Block End Packet (BEP), report them as a new Intel PT sample type INTEL_PT_BLK_ITEMS. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190610072803.10456-4-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Add Intel PT packet decoder test. This test feeds byte sequences to the Intel PT packet decoder and checks the results. Changes to the packet context are also checked. Committer testing: # perf test "Intel PT" 65: Intel PT packet decoder : Ok # perf test -v "Intel PT" 65: Intel PT packet decoder : --- start --- test child forked, pid 6360 Decoded ok: 00 PAD Decoded ok: 04 TNT N (1) Decoded ok: 06 TNT T (1) Decoded ok: 80 TNT NNNNNN (6) Decoded ok: fe TNT TTTTTT (6) Decoded ok: 02 a3 02 00 00 00 00 00 TNT N (1) Decoded ok: 02 a3 03 00 00 00 00 00 TNT T (1) Decoded ok: 02 a3 00 00 00 00 00 80 TNT NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN (47) Decoded ok: 02 a3 ff ff ff ff ff ff TNT TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT (47) Decoded ok: 0d TIP no ip Decoded ok: 2d 01 02 TIP 0x201 Decoded ok: 4d 01 02 03 04 TIP 0x4030201 Decoded ok: 6d 01 02 03 04 05 06 TIP 0x60504030201 Decoded ok: 8d 01 02 03 04 05 06 TIP 0x60504030201 Decoded ok: cd 01 02 03 04 05 06 07 08 TIP 0x807060504030201 Decoded ok: 11 TIP.PGE no ip Decoded ok: 31 01 02 TIP.PGE 0x201 Decoded ok: 51 01 02 03 04 TIP.PGE 0x4030201 Decoded ok: 71 01 02 03 04 05 06 TIP.PGE 0x60504030201 Decoded ok: 91 01 02 03 04 05 06 TIP.PGE 0x60504030201 Decoded ok: d1 01 02 03 04 05 06 07 08 TIP.PGE 0x807060504030201 Decoded ok: 01 TIP.PGD no ip Decoded ok: 21 01 02 TIP.PGD 0x201 Decoded ok: 41 01 02 03 04 TIP.PGD 0x4030201 Decoded ok: 61 01 02 03 04 05 06 TIP.PGD 0x60504030201 Decoded ok: 81 01 02 03 04 05 06 TIP.PGD 0x60504030201 Decoded ok: c1 01 02 03 04 05 06 07 08 TIP.PGD 0x807060504030201 Decoded ok: 1d FUP no ip Decoded ok: 3d 01 02 FUP 0x201 Decoded ok: 5d 01 02 03 04 FUP 0x4030201 Decoded ok: 7d 01 02 03 04 05 06 FUP 0x60504030201 Decoded ok: 9d 01 02 03 04 05 06 FUP 0x60504030201 Decoded ok: dd 01 02 03 04 05 06 07 08 FUP 0x807060504030201 Decoded ok: 02 43 02 04 06 08 0a 0c PIP 0x60504030201 (NR=0) Decoded ok: 02 43 03 04 06 08 0a 0c PIP 0x60504030201 (NR=1) Decoded ok: 99 00 MODE.Exec 16 Decoded ok: 99 01 MODE.Exec 64 Decoded ok: 99 02 MODE.Exec 32 Decoded ok: 99 20 MODE.TSX TXAbort:0 InTX:0 Decoded ok: 99 21 MODE.TSX TXAbort:0 InTX:1 Decoded ok: 99 22 MODE.TSX TXAbort:1 InTX:0 Decoded ok: 02 83 TraceSTOP Decoded ok: 02 03 12 00 CBR 0x12 Decoded ok: 19 01 02 03 04 05 06 07 TSC 0x7060504030201 Decoded ok: 59 12 MTC 0x12 Decoded ok: 02 73 00 00 00 00 00 TMA CTC 0x0 FC 0x0 Decoded ok: 02 73 01 02 00 00 00 TMA CTC 0x201 FC 0x0 Decoded ok: 02 73 00 00 00 ff 01 TMA CTC 0x0 FC 0x1ff Decoded ok: 02 73 80 c0 00 ff 01 TMA CTC 0xc080 FC 0x1ff Decoded ok: 03 CYC 0x0 Decoded ok: 0b CYC 0x1 Decoded ok: fb CYC 0x1f Decoded ok: 07 02 CYC 0x20 Decoded ok: ff fe CYC 0xfff Decoded ok: 07 01 02 CYC 0x1000 Decoded ok: ff ff fe CYC 0x7ffff Decoded ok: 07 01 01 02 CYC 0x80000 Decoded ok: ff ff ff fe CYC 0x3ffffff Decoded ok: 07 01 01 01 02 CYC 0x4000000 Decoded ok: ff ff ff ff fe CYC 0x1ffffffff Decoded ok: 07 01 01 01 01 02 CYC 0x200000000 Decoded ok: ff ff ff ff ff fe CYC 0xffffffffff Decoded ok: 07 01 01 01 01 01 02 CYC 0x10000000000 Decoded ok: ff ff ff ff ff ff fe CYC 0x7fffffffffff Decoded ok: 07 01 01 01 01 01 01 02 CYC 0x800000000000 Decoded ok: ff ff ff ff ff ff ff fe CYC 0x3fffffffffffff Decoded ok: 07 01 01 01 01 01 01 01 02 CYC 0x40000000000000 Decoded ok: ff ff ff ff ff ff ff ff fe CYC 0x1fffffffffffffff Decoded ok: 07 01 01 01 01 01 01 01 01 02 CYC 0x2000000000000000 Decoded ok: ff ff ff ff ff ff ff ff ff 0e CYC 0xffffffffffffffff Decoded ok: 02 c8 01 02 03 04 05 VMCS 0x504030201 Decoded ok: 02 f3 OVF Decoded ok: 02 f3 OVF Decoded ok: 02 f3 OVF Decoded ok: 02 82 02 82 02 82 02 82 02 82 02 82 02 82 02 82 PSB Decoded ok: 02 82 02 82 02 82 02 82 02 82 02 82 02 82 02 82 PSB Decoded ok: 02 82 02 82 02 82 02 82 02 82 02 82 02 82 02 82 PSB Decoded ok: 02 23 PSBEND Decoded ok: 02 c3 88 01 02 03 04 05 06 07 00 MNT 0x7060504030201 Decoded ok: 02 12 01 02 03 04 PTWRITE 0x4030201 IP:0 Decoded ok: 02 32 01 02 03 04 05 06 07 08 PTWRITE 0x807060504030201 IP:0 Decoded ok: 02 92 01 02 03 04 PTWRITE 0x4030201 IP:1 Decoded ok: 02 b2 01 02 03 04 05 06 07 08 PTWRITE 0x807060504030201 IP:1 Decoded ok: 02 62 EXSTOP IP:0 Decoded ok: 02 e2 EXSTOP IP:1 Decoded ok: 02 c2 00 00 00 00 00 00 00 00 MWAIT 0x0 Hints 0x0 Extensions 0x0 Decoded ok: 02 c2 01 02 03 04 05 06 07 08 MWAIT 0x807060504030201 Hints 0x1 Extensions 0x1 Decoded ok: 02 c2 ff 02 03 04 07 06 07 08 MWAIT 0x8070607040302ff Hints 0xff Extensions 0x3 Decoded ok: 02 22 00 00 PWRE 0x0 HW:0 CState:0 Sub-CState:0 Decoded ok: 02 22 01 02 PWRE 0x201 HW:0 CState:0 Sub-CState:2 Decoded ok: 02 22 80 34 PWRE 0x3480 HW:1 CState:3 Sub-CState:4 Decoded ok: 02 22 00 56 PWRE 0x5600 HW:0 CState:5 Sub-CState:6 Decoded ok: 02 a2 00 00 00 00 00 PWRX 0x0 Last CState:0 Deepest CState:0 Wake Reason 0x0 Decoded ok: 02 a2 01 02 03 04 05 PWRX 0x504030201 Last CState:0 Deepest CState:1 Wake Reason 0x2 Decoded ok: 02 a2 ff ff ff ff ff PWRX 0xffffffffff Last CState:15 Deepest CState:15 Wake Reason 0xf Decoded ok: 02 63 00 BBP SZ 8-byte Type 0x0 Decoded ok: 02 63 80 BBP SZ 4-byte Type 0x0 Decoded ok: 02 63 1f BBP SZ 8-byte Type 0x1f Decoded ok: 02 63 9f BBP SZ 4-byte Type 0x1f Decoded ok: 04 00 00 00 00 BIP ID 0x00 Value 0x0 Decoded ok: fc 00 00 00 00 BIP ID 0x1f Value 0x0 Decoded ok: 04 01 02 03 04 BIP ID 0x00 Value 0x4030201 Decoded ok: fc 01 02 03 04 BIP ID 0x1f Value 0x4030201 Decoded ok: 04 00 00 00 00 00 00 00 00 BIP ID 0x00 Value 0x0 Decoded ok: fc 00 00 00 00 00 00 00 00 BIP ID 0x1f Value 0x0 Decoded ok: 04 01 02 03 04 05 06 07 08 BIP ID 0x00 Value 0x807060504030201 Decoded ok: fc 01 02 03 04 05 06 07 08 BIP ID 0x1f Value 0x807060504030201 Decoded ok: 02 33 BEP IP:0 Decoded ok: 02 b3 BEP IP:1 Decoded ok: 02 33 BEP IP:0 Decoded ok: 02 b3 BEP IP:1 test child finished with 0 ---- end ---- Intel PT packet decoder: Ok # Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190610072803.10456-3-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Add 3 new packets to supports PEBS via PT, namely Block Begin Packet (BBP), Block Item Packet (BIP) and Block End Packet (BEP). PEBS data is encoded into multiple BIP packets that come between BBP and BEP. The BEP packet might be associated with a FUP packet. That is indicated by using a separate packet type (INTEL_PT_BEP_IP) similar to other packets types with the _IP suffix. Refer to the Intel SDM for more information about PEBS via PT: https://software.intel.com/en-us/articles/intel-sdm May 2019 version: Vol. 3B 18.5.5.2 PEBS output to Intel® Processor Trace Decoding of BIP packets conflicts with single-byte TNT packets. Since BIP packets only occur in the context of a block (i.e. between BBP and BEP), that context must be recorded and passed to the packet decoder. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190610072803.10456-2-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Mathieu Poirier 提交于
Call function cs_etm_set_option() once with all relevant options set rather than multiple times to avoid going through the list of CPU more than once. Suggested-by: NSuzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20190611204528.20093-1-mathieu.poirier@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Raphael Gault 提交于
In order to subsequently add more tests for the arm64 architecture we compile the tests target for arm64 systematically. Further explanation provided by Mark Rutland: Given prior questions regarding this commit, it's probably worth spelling things out more explicitly, e.g. Currently we only build the arm64/tests directory if CONFIG_DWARF_UNWIND is selected, which is fine as the only test we have is arm64/tests/dwarf-unwind.o. So that we can add more tests to the test directory, let's unconditionally build the directory, but conditionally build dwarf-unwind.o depending on CONFIG_DWARF_UNWIND. There should be no functional change as a result of this patch. Signed-off-by: NRaphael Gault <raphael.gault@arm.com> Acked-by: NMark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20190611125315.18736-2-raphael.gault@arm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
- 11 6月, 2019 25 次提交
-
-
由 Arnaldo Carvalho de Melo 提交于
We have $INSTALL_DIR/share/perf-core/strace/groups/string files with syscalls that should be selected when 'string' is used, meaning, in this case, syscalls that receive as one of its arguments a string, like a pathname. But those were first selected and tested on x86_64, and end up failing in architectures where some of those syscalls are not available, like the 'access' syscall on arm64, which makes using 'perf trace -e string' in such archs to fail. Since this the routine doing the validation is used only when reading such files, do not fail when some syscall is not found in the syscalltbl, instead just use pr_debug() to register that in case people are suspicious of problems. Now using 'perf trace -e string' should work on arm64, selecting only the syscalls that have a string and are available on that architecture. Reported-by: NLeo Yan <leo.yan@linaro.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Martin KaFai Lau <kafai@fb.com> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Mike Leach <mike.leach@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Song Liu <songliubraving@fb.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Yonghong Song <yhs@fb.com> Link: https://lkml.kernel.org/r/20190610184754.GU21245@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Thomas Richter 提交于
Perf report fails to display s390 specific event numbered bd000 on an x86 platform. For example on s390 this works without error: [root@m35lp76 perf]# uname -m s390x [root@m35lp76 perf]# ./perf record -e rbd000 -- find / >/dev/null [ perf record: Woken up 3 times to write data ] [ perf record: Captured and wrote 0.549 MB perf.data ] [root@m35lp76 perf]# ./perf report -D --stdio > /dev/null [root@m35lp76 perf]# Transfering this perf.data file to an x86 platform and executing the same report command produces: [root@f29 perf]# uname -m x86_64 [root@f29 perf]# ./perf report -i ~/perf.data.m35lp76 --stdio interpreting bpf_prog_info from systems with endianity is not yet supported interpreting btf from systems with endianity is not yet supported 0x8c890 [0x8]: failed to process type: 68 Error: failed to process sample Event bd000 generates auxiliary data which is stored in big endian format in the perf data file. This error is caused by missing endianess handling on the x86 platform when the data is displayed. Fix this by handling s390 auxiliary event data depending on the local platform endianness. Output after on x86: [root@f29 perf]# ./perf report -D -i ~/perf.data.m35lp76 --stdio > /dev/null interpreting bpf_prog_info from systems with endianity is not yet supported interpreting btf from systems with endianity is not yet supported [root@f29 perf]# Committer notes: Fix build breakage on older systems, such as CentOS:6 where using nesting calls to the endian.h macros end up redefining local variables: util/s390-cpumsf.c: In function 's390_cpumsf_trailer_show': util/s390-cpumsf.c:333: error: declaration of '__v' shadows a previous local util/s390-cpumsf.c:333: error: shadowed declaration is here util/s390-cpumsf.c:333: error: declaration of '__x' shadows a previous local util/s390-cpumsf.c:333: error: shadowed declaration is here util/s390-cpumsf.c:334: error: declaration of '__v' shadows a previous local util/s390-cpumsf.c:334: error: shadowed declaration is here util/s390-cpumsf.c:334: error: declaration of '__x' shadows a previous local util/s390-cpumsf.c:334: error: shadowed declaration is here [perfbuilder@455a63ef60dc perf]$ gcc -v |& tail -1 gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC) [perfbuilder@455a63ef60dc perf]$ Since there are several uses of be64toh(te->flags) Introduce a variable to hold that and then use it, avoiding this case that causes the above problems: - local.bsdes = be16toh((be64toh(te->flags) >> 16 & 0xffff)); + local.bsdes = be16toh((flags >> 16 & 0xffff)); Its the same construct used in s390_cpumsf_diag_show() where we have a 'word' variable that is used just once, s390_cpumsf_basic_show() has lots of uses and also uses a variable to hold the result of be16toh(). Some of those temp variables needed to be converted from 'unsigned long' to 'unsigned long long' so as to build on 32-bit arches such as debian:experimental-x-mipsel, the android NDK ones and fedora:24-x-ARC-uClibc. Signed-off-by: NThomas Richter <tmricht@linux.ibm.com> Reviewed-by: NHendrik Brueckner <brueckner@linux.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Link: http://lkml.kernel.org/r/20190522064325.25596-1-tmricht@linux.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Thomas Richter 提交于
Debugging a OOM error using the TUI interface revealed this issue on s390: [tmricht@m83lp54 perf]$ cat /proc/kallsyms |sort .... 00000001119b7158 B radix_tree_node_cachep 00000001119b8000 B __bss_stop 00000001119b8000 B _end 000003ff80002850 t autofs_mount [autofs4] 000003ff80002868 t autofs_show_options [autofs4] 000003ff80002a98 t autofs_evict_inode [autofs4] .... There is a huge gap between the last kernel symbol __bss_stop/_end and the first kernel module symbol autofs_mount (from autofs4 module). After reading the kernel symbol table via functions: dso__load() +--> dso__load_kernel_sym() +--> dso__load_kallsyms() +--> __dso_load_kallsyms() +--> symbols__fixup_end() the symbol __bss_stop has a start address of 1119b8000 and an end address of 3ff80002850, as can be seen by this debug statement: symbols__fixup_end __bss_stop start:0x1119b8000 end:0x3ff80002850 The size of symbol __bss_stop is 0x3fe6e64a850 bytes! It is the last kernel symbol and fills up the space until the first kernel module symbol. This size kills the TUI interface when executing the following code: process_sample_event() hist_entry_iter__add() hist_iter__report_callback() hist_entry__inc_addr_samples() symbol__inc_addr_samples(symbol = __bss_stop) symbol__cycles_hist() annotated_source__alloc_histograms(..., symbol__size(sym), ...) This function allocates memory to save sample histograms. The symbol_size() marco is defined as sym->end - sym->start, which results in above value of 0x3fe6e64a850 bytes and the call to calloc() in annotated_source__alloc_histograms() fails. The histgram memory allocation might fail, make this failure no-fatal and continue processing. Output before: [tmricht@m83lp54 perf]$ ./perf --debug stderr=1 report -vvvvv \ -i ~/slow.data 2>/tmp/2 [tmricht@m83lp54 perf]$ tail -5 /tmp/2 __symbol__inc_addr_samples(875): ENOMEM! sym->name=__bss_stop, start=0x1119b8000, addr=0x2aa0005eb08, end=0x3ff80002850, func: 0 problem adding hist entry, skipping event 0x938b8 [0x8]: failed to process type: 68 [Cannot allocate memory] [tmricht@m83lp54 perf]$ Output after: [tmricht@m83lp54 perf]$ ./perf --debug stderr=1 report -vvvvv \ -i ~/slow.data 2>/tmp/2 [tmricht@m83lp54 perf]$ tail -5 /tmp/2 symbol__inc_addr_samples map:0x1597830 start:0x110730000 end:0x3ff80002850 symbol__hists notes->src:0x2aa2a70 nr_hists:1 symbol__inc_addr_samples sym:unlink_anon_vmas src:0x2aa2a70 __symbol__inc_addr_samples: addr=0x11094c69e 0x11094c670 unlink_anon_vmas: period++ [addr: 0x11094c69e, 0x2e, evidx=0] => nr_samples: 1, period: 526008 [tmricht@m83lp54 perf]$ There is no error about failed memory allocation and the TUI interface shows all entries. Signed-off-by: NThomas Richter <tmricht@linux.ibm.com> Reviewed-by: NHendrik Brueckner <brueckner@linux.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/90cb5607-3e12-5167-682d-978eba7dafa8@linux.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Thomas Richter 提交于
Command # perf test -Fv 6 fails with error running test 100 'kvm-s390:kvm_s390_create_vm' failed to parse event 'kvm-s390:kvm_s390_create_vm', err -1, str 'unknown tracepoint' event syntax error: 'kvm-s390:kvm_s390_create_vm' \___ unknown tracepoint when the kvm module is not loaded or not built in. Fix this by adding a valid function which tests if the module is loaded. Loaded modules (or builtin KVM support) have a directory named /sys/kernel/debug/tracing/events/kvm-s390 for this tracepoint. Check for existence of this directory. Signed-off-by: NThomas Richter <tmricht@linux.ibm.com> Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/20190604053504.43073-1-tmricht@linux.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Currently only a single explicit time range is accepted. Add support for multiple ranges separated by spaces, which requires the string to be quoted. Update the time utils test accordingly. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-20-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Test time ranges work as expected. Committer testing: $ perf test "time utils" 59: time utils : Ok $ perf test -v "time utils" 59: time utils : --- start --- test child forked, pid 31711 parse_nsec_time("0") 0 parse_nsec_time("1") 1000000000 parse_nsec_time("0.000000001") 1 parse_nsec_time("1.000000001") 1000000001 parse_nsec_time("123456.123456") 123456123456000 parse_nsec_time("1234567.123456789") 1234567123456789 parse_nsec_time("18446744073.709551615") 18446744073709551615 perf_time__parse_str("1234567.123456789,1234567.123456789") start time 1234567123456789, end time 1234567123456789 perf_time__parse_str("1234567.123456789,1234567.123456790") start time 1234567123456789, end time 1234567123456790 perf_time__parse_str("1234567.123456789,") start time 1234567123456789, end time 0 perf_time__parse_str(",1234567.123456789") start time 0, end time 1234567123456789 perf_time__parse_str("0,1234567.123456789") start time 0, end time 1234567123456789 perf_time__parse_for_ranges("1234567.123456789,1234567.123456790") start time 1234567123456789, end time 1234567123456790 perf_time__parse_for_ranges("10%/1") first_sample_time 7654321000000000 last_sample_time 7654321000000100 start time 0: 7654321000000000, end time 0: 7654321000000009 perf_time__parse_for_ranges("10%/2") first_sample_time 7654321000000000 last_sample_time 7654321000000100 start time 0: 7654321000000010, end time 0: 7654321000000019 perf_time__parse_for_ranges("10%/1,10%/2") first_sample_time 11223344000000000 last_sample_time 11223344000000100 start time 0: 11223344000000000, end time 0: 11223344000000009 start time 1: 11223344000000010, end time 1: 11223344000000019 perf_time__parse_for_ranges("10%/1,10%/3,10%/10") first_sample_time 11223344000000000 last_sample_time 11223344000000100 start time 0: 11223344000000000, end time 0: 11223344000000009 start time 1: 11223344000000020, end time 1: 11223344000000029 start time 2: 11223344000000090, end time 2: 11223344000000100 test child finished with 0 ---- end ---- time utils: Ok $ Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-19-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Explicit time ranges never contain a percent sign whereas percentage ranges always do, so it is possible to call the correct parser. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-18-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Simplify perf_time__parse_for_ranges() error paths slightly. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-17-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Correct some punctuation and spelling and correct the format to show that the time resolution is nanoseconds not microseconds. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-16-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Prevent percentage time range overlap. This is only a 1 nanosecond change but makes the results more logical e.g. a sample cannot be in both the first 10% and the second 20%. Note, there is a later patch that adds a test for time-utils. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-15-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Factor out set_percent_time() so it can be reused. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-14-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Currently, options allow only 1 explicit (non-percentage) time range. In preparation for adding support for multiple explicit time ranges, treat time ranges consistently. Instead of treating some time ranges as inclusive and some as excluding the end time, treat all time ranges as inclusive. This is only a 1 nanosecond change but is necessary to treat multiple explicit time ranges in a consistent manner. Note, there is a later patch that adds a test for time-utils. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-13-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Set up time ranges for efficient time interval filtering using the new "fast forward" facility. Because decoding is done in time order, intel_pt_time_filter() needs to look only at the next start or end timestamp - refer intel_pt_next_time(). Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-12-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Implement the lookahead callback to let the decoder access subsequent buffers. intel_pt_lookahead() manages the buffer lifetime and calls the decoder for each buffer until the decoder returns a non-zero value. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-11-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Factor out intel_pt_get_buffer() so it can be reused. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-10-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Intel PT decoding is done in time order. In order to support efficient time interval filtering, add a facility to "fast forward" towards a particular timestamp. That involves finding the right buffer, stepping to that buffer, and then stepping forward PSBs. Because decoding must begin at a PSB, "fast forward" stops at the last PSB that has a timestamp before the target timestamp. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-9-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
When the decoder gets the next trace buffer, some state is reset if the buffer is not consecutive to the previous buffer. Add a parameter 'reposition' so that can be done also to support a "fast forward" facility. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-8-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Factor out intel_pt_reposition() so it can be reused. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-7-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Factor out intel_pt_8b_tsc() so it can be reused. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-6-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Add a callback function to enable the decoder to lookahead at subsequent trace buffers. This will be used to implement a "fast forward" facility which will be needed to support efficient time interval filtering. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-5-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Instruction trace decoders can optimize output based on what time intervals will be filtered, so pass that information in itrace_synth_ops. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-4-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Instruction trace decoders can optimize output based on what time intervals will be filtered, so pass that information in itrace_synth_ops. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-3-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Adrian Hunter 提交于
Instruction trace decoders can optimize output based on what time intervals will be filtered, so pass that information in itrace_synth_ops. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190604130017.31207-2-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Leo Yan 提交于
The clang bpf cmdline template has defined default value in the file tools/perf/util/llvm-utils.c, which has been changed for several times. This patch updates the documentation to reflect the latest default value for the configuration llvm.clang-bpf-cmd-template. Signed-off-by: NLeo Yan <leo.yan@linaro.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Drayton <mbd@fb.com> Cc: Martin KaFai Lau <kafai@fb.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Song Liu <songliubraving@fb.com> Cc: Yonghong Song <yhs@fb.com> Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Fixes: d35b168c ("perf bpf: Give precedence to bpf header dir") Fixes: cb763714 ("perf llvm: Allow passing options to llc in addition to clang") Fixes: 1b16fffa ("perf llvm-utils: Add bpf include path to clang command line") Link: http://lkml.kernel.org/r/20190607143508.18141-1-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Arnaldo Carvalho de Melo 提交于
Suzuki noticed that this should be more useful in a generic header, and after looking I noticed we have it already in our copy of include/linux/bits.h in tools/include, so just use it, test built on x86-64 and ubuntu 19.04 with: perfbuilder@46646c9e848e:/$ aarch64-linux-gnu-gcc --version |& head -1 aarch64-linux-gnu-gcc (Ubuntu/Linaro 8.3.0-6ubuntu1) 8.3.0 perfbuilder@46646c9e848e:/$ Suggested-by: NSuzuki K Poulose <suzuki.poulose@arm.com> Link: https://lkml.kernel.org/r/68c1c548-33cd-31e8-100d-7ffad008c7b2@arm.com Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Leo Yan <leo.yan@linaro.org> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: coresight@lists.linaro.org Cc: linux-arm-kernel@lists.infradead.org, Link: https://lkml.kernel.org/n/tip-69pd3mqvxdlh2shddsc7yhyv@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-