kernel/linux.git/tools/perf/util/header.c, branch v5.9.2

perf tools: Fix module symbol processing

2020-08-13T12:57:40+00:00

The 'dso->kernel' condition is true also for kernel modules now, and there are several places that were omited by the initial change: - we need to identify modules separately in dso__process_kernel_symbol - we need to set 'dso->kernel' for module from buildid table - there's no need to use 'dso->kernel || kmodule' in one condition Committer testing: Before: # perf test -v object Objdump command is: objdump -z -d --start-address=0xffffffff813e682f --stop-address=0xffffffff813e68af /usr/lib/debug/lib/modules/5.7.14-200.fc32.x86_64/vmlinux Bytes read match those read by objdump Reading object code for memory address: 0xffffffffc02dc257 File is: /lib/modules/5.7.14-200.fc32.x86_64/kernel/arch/x86/crypto/crc32c-intel.ko.xz On file address is: 0xffffffffc02dc2e7 dso__data_read_offset failed test child finished with -1 ---- end ---- Object code reading: FAILED! # After: # perf test object 26: Object code reading : Ok # perf test object 26: Object code reading : Ok # perf test object 26: Object code reading : Ok # perf test object 26: Object code reading : Ok # perf test object 26: Object code reading : Ok # Fixes: 02213cec64bb ("perf maps: Mark module DSOs with kernel type") Reported-by: Arnaldo Carvalho de Melo Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Namhyung Kim Signed-off-by: Jiri Olsa

perf tools: Rename 'enum dso_kernel_type' to 'enum dso_space_type'

2020-08-13T12:53:21+00:00

Rename enum dso_kernel_type to enum dso_space_type, which seems like better fit. Committer notes: This is used with 'struct dso'->kernel, which once was a boolean, so DSO_SPACE__USER is zero, !zero means some sort of kernel space, be it the host kernel space or a guest kernel space. Signed-off-by: Jiri Olsa Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Move clockid_res_ns under clock struct

2020-08-06T12:42:20+00:00

Move the clockid_res_ns struct member to the clock struct, so we have the clock related stuff in one place. Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: Andi Kleen Cc: David Ahern Cc: Geneviève Bastien Cc: Ian Rogers Cc: Jeremie Galarneau Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Wang Nan Link: http://lore.kernel.org/lkml/20200805093444.314999-5-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf header: Store clock references for -k/--clockid option

2020-08-06T12:35:06+00:00

Add a new CLOCK_DATA feature that stores reference times when -k/--clockid option is specified. It contains the clock id and its reference time together with wall clock time taken at the 'same time', both values are in nanoseconds. The format of data is as below: struct { u32 version; /* version = 1 */ u32 clockid; u64 wall_clock_ns; u64 clockid_time_ns; }; This clock reference times will be used in following changes to display wall clock for perf events. It's available only for recording with clockid specified, because it's the only case where we can get reference time to wallclock time. It's can't do that with perf clock yet. Committer testing: $ perf record -h -k Usage: perf record [] [] or: perf record [] -- [] -k, --clockid clockid to use for events, see clock_gettime() $ perf record -k monotonic sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.017 MB perf.data (8 samples) ] $ perf report --header-only | grep clockid -A1 # event : name = cycles:u, , id = { 88815, 88816, 88817, 88818, 88819, 88820, 88821, 88822 }, size = 120, { sample_period, sample_freq } = 4000, sample_type = IP|TID|TIME|PERIOD, read_format = ID, disabled = 1, inherit = 1, exclude_kernel = 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, use_clockid = 1, ksymbol = 1, bpf_event = 1, clockid = 1 # CPU_TOPOLOGY info available, use -I to display -- # clockid frequency: 1000 MHz # cpu pmu capabilities: branches=32, max_precise=3, pmu_name=skylake # clockid: monotonic (1) # reference time: 2020-08-06 09:40:21.619290 = 1596717621.619290 (TOD) = 21931.077673635 (monotonic) $ Original-patch-by: David Ahern Signed-off-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Andi Kleen Cc: David Ahern Cc: Geneviève Bastien Cc: Ian Rogers Cc: Jeremie Galarneau Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Wang Nan Link: http://lore.kernel.org/lkml/20200805093444.314999-4-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf session: Try to read pipe data from file

2020-05-28T13:03:25+00:00

Ian came with the idea of having support to read the pipe data also from file. Currently pipe mode files fail like: $ perf record -o - sleep 1 > /tmp/perf.pipe.data $ perf report -i /tmp/perf.pipe.data incompatible file format (rerun with -v to learn more) This patch adds the support to do that by trying the pipe header first, and if its successfully detected, switching the perf data to pipe mode. Committer testing: # ls # perf record -a -o - sleep 1 > /tmp/perf.pipe.data [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.000 MB - ] # ls # perf report -i /tmp/perf.pipe.data | head -25 # To display the perf.data header info, please use --header/--header-only options. # # # Total Lost Samples: 0 # # Samples: 511 of event 'cycles' # Event count (approx.): 178447276 # # Overhead Command Shared Object Symbol # ........ ........ ................. ........................................................................................... # 65.49% swapper [kernel.kallsyms] [k] native_safe_halt 6.45% chromium libblink_core.so [.] blink::SelectorChecker::CheckOne 4.08% chromium libblink_core.so [.] blink::SelectorQuery::ExecuteForTraverseRoot 2.25% chromium libblink_core.so [.] blink::SelectorQuery::FindTraverseRootsAndExecute 2.11% chromium libblink_core.so [.] blink::SelectorChecker::MatchSelector 1.91% chromium libblink_core.so [.] blink::Node::OwnerShadowHost 1.31% chromium libblink_core.so [.] blink::Node::parentNode@plt 1.22% chromium libblink_core.so [.] blink::Node::parentNode 0.59% chromium libblink_core.so [.] blink::AnyAttributeMatches 0.58% chromium libv8.so [.] v8::internal::GlobalHandles::Create 0.58% chromium libblink_core.so [.] blink::NodeTraversal::NextAncestorSibling 0.55% chromium libv8.so [.] v8::internal::RegExpGlobalCache::RegExpGlobalCache 0.55% chromium libblink_core.so [.] blink::Node::ContainingShadowRoot 0.55% chromium libblink_core.so [.] blink::NodeTraversal::NextAncestorSibling@plt # Original-patch-by: Ian Rogers Signed-off-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Ian Rogers Cc: Michael Petlan Cc: Namhyung Kim Cc: Paul Khuong Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200507095024.2789147-4-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Do not seek in pipe fd during tracing data processing

2020-05-28T13:03:25+00:00

There's no need to set 'fd' position in pipe mode, the file descriptor is already in proper place. Moreover the lseek will fail on pipe descriptor and that's why it's been working properly. I was tempted to remove the lseek calls completely, because it seems that tracing data event was always synthesized only in pipe mode, so there's no need for 'file' mode handling. But I guess there was a reason behind this and there might (however unlikely) be a perf.data that we could break processing for. Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: Ian Rogers Cc: Michael Petlan Cc: Namhyung Kim Cc: Paul Khuong Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200507095024.2789147-3-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf evsel: Rename perf_evsel__is_() to evsel__is()

2020-05-05T19:35:31+00:00

As those are 'struct evsel' methods, not part of tools/lib/perf/, aka libperf, to whom the perf_ prefix belongs. Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Signed-off-by: Arnaldo Carvalho de Melo

perf evsel: Rename perf_evselname() to evselname()

2020-05-05T19:35:30+00:00

As they are 'struct evsel' methods or related routines, not part of tools/lib/perf/, aka libperf, to whom the perf_ prefix belongs. Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Signed-off-by: Arnaldo Carvalho de Melo

perf header: Support CPU PMU capabilities

2020-04-18T12:05:00+00:00

To stitch LBR call stack, the max LBR information is required. So the CPU PMU capabilities information has to be stored in perf header. Add a new feature HEADER_CPU_PMU_CAPS for CPU PMU capabilities. Retrieve all CPU PMU capabilities, not just max LBR information. Add variable max_branches to facilitate future usage. Committer testing: # ls -la /sys/devices/cpu/caps/ total 0 drwxr-xr-x. 2 root root 0 Apr 17 10:53 . drwxr-xr-x. 6 root root 0 Apr 17 07:02 .. -r--r--r--. 1 root root 4096 Apr 17 10:53 max_precise # # cat /sys/devices/cpu/caps/max_precise 0 # perf record sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.033 MB perf.data (7 samples) ] # # perf report --header-only | egrep 'cpu(desc|.*capabilities)' # cpudesc : AMD Ryzen 5 3600X 6-Core Processor # cpu pmu capabilities: max_precise=0 # And then on an Intel machine: $ ls -la /sys/devices/cpu/caps/ total 0 drwxr-xr-x. 2 root root 0 Apr 17 10:51 . drwxr-xr-x. 6 root root 0 Apr 17 10:04 .. -r--r--r--. 1 root root 4096 Apr 17 11:37 branches -r--r--r--. 1 root root 4096 Apr 17 10:51 max_precise -r--r--r--. 1 root root 4096 Apr 17 11:37 pmu_name $ cat /sys/devices/cpu/caps/max_precise 3 $ cat /sys/devices/cpu/caps/branches 32 $ cat /sys/devices/cpu/caps/pmu_name skylake $ perf record sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.001 MB perf.data (8 samples) ] $ perf report --header-only | egrep 'cpu(desc|.*capabilities)' # cpudesc : Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz # cpu pmu capabilities: branches=32, max_precise=3, pmu_name=skylake $ Signed-off-by: Kan Liang Reviewed-by: Andi Kleen Acked-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexey Budankov Cc: Mathieu Poirier Cc: Michael Ellerman Cc: Namhyung Kim Cc: Pavel Gerasimov Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Stephane Eranian Cc: Vitaly Slobodskoy Link: http://lore.kernel.org/lkml/20200319202517.23423-3-kan.liang@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo

perf header: Add check for unexpected use of reserved membrs in event attr

2020-03-10T00:43:24+00:00

The perf.data may be generated by a newer version of perf tool, which support new input bits in attr, e.g. new bit for branch_sample_type. The perf.data may be parsed by an older version of perf tool later. The old perf tool may parse the perf.data incorrectly. There is no warning message for this case. Current perf header never check for unknown input bits in attr. When read the event desc from header, check the stored event attr. The reserved bits, sample type, read format and branch sample type will be checked. Signed-off-by: Kan Liang Cc: Adrian Hunter Cc: Alexey Budankov Cc: Andi Kleen Cc: Jiri Olsa Cc: Mathieu Poirier Cc: Michael Ellerman Cc: Namhyung Kim Cc: Pavel Gerasimov Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Stephane Eranian Cc: Vitaly Slobodskoy Link: http://lkml.kernel.org/r/20200228163011.19358-4-kan.liang@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo