- 28 May, 2020 40 commits
-
-
Ian Rogers authored
Allow use of hashmap in perf. Modify perf's check-headers.sh script to check that the files are kept in sync, in the same way kernel headers are checked. This will warn if they are out of sync at the start of a perf build. Committer note: This starts out of synch as a fix went thru the bpf tree, namely the one removing the needless libbpf_internal.h include in hashmap.h. There is also another change related to __WORDSIZE, that as is in tools/lib/bpf/hashmap.h causes the tools/perf/ build to fail in systems such as Alpine Linus, that uses the Musl libc, so we need an alternative way of having __WORDSIZE available, use the one used by tools/include/linux/bitops.h, that builds in all the systems I have build containers for. These differences will be resolved at some point, so keep the warning in check-headers.sh as a reminder. Signed-off-by:
Ian Rogers <irogers@google.com> Acked-by:
Andrii Nakryiko <andriin@fb.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: John Fastabend <john.fastabend@gmail.com> Cc: John Garry <john.garry@huawei.com> Cc: Kajol Jain <kjain@linux.ibm.com> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Kim Phillips <kim.phillips@amd.com> Cc: Leo Yan <leo.yan@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Martin KaFai Lau <kafai@fb.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Song Liu <songliubraving@fb.com> Cc: Stephane Eranian <eranian@google.com> Cc: Yonghong Song <yhs@fb.com> Cc: bpf@vger.kernel.org Cc: kp singh <kpsingh@chromium.org> Cc: netdev@vger.kernel.org Link: http://lore.kernel.org/lkml/20200515221732.44078-5-irogers@google.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Jiri Olsa authored
Joakim reported wrong duration_time value for interval bigger than 4000 [1]. The problem is in the interval value we pass to update_stats function, which is typed as 'unsigned int' and overflows when we get over 2^32 (happens between intervals 4000 and 5000). Retyping the passed value to unsigned long long. [1] https://www.spinics.net/lists/linux-perf-users/msg11777.html Fixes: b90f1333 ("perf stat: Update walltime_nsecs_stats in interval mode") Reported-by:
Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20200518131445.3745083-1-jolsa@kernel.orgSigned-off-by:
-
Jiri Olsa authored
The perf compilation fails for NO_LIBBPF=1 DEBUG=1 with: $ make NO_LIBBPF=1 DEBUG=1 BUILD: Doing 'make -j8' parallel build CC builtin-trace.o LD perf-in.o LINK perf /usr/bin/ld: perf-in.o: in function `trace__find_bpf_map_by_name': /home/jolsa/kernel/linux-perf/tools/perf/builtin-trace.c:4608: undefined reference to `bpf_object__find_map_by_name' collect2: error: ld returned 1 exit status make[2]: *** [Makefile.perf:631: perf] Error 1 make[1]: *** [Makefile.perf:225: sub-make] Error 2 make: *** [Makefile:70: all] Error 2 Move trace__find_bpf_map_by_name calls under HAVE_LIBBPF_SUPPORT ifdef and add make test for this. Committer notes: Add missing: run += make_no_libbpf_DEBUG Signed-off-by: -
Ian Rogers authored
Allow the CC compiler to accept a CFLAGS environment variable. This doesn't change the code generated but makes it easier to integrate running the shell script in build systems like bazel. Signed-off-by:
-
Ian Rogers authored
Make the architecture test directory agree with the code comment. Committer notes: This was split from a larger patch. The code was assuming the developer always worked from tools/perf/, so make sure we do the test -d having $toolsdir/perf/arch/$arch, to match the intent expressed in the comment, just above that loop. Signed-off-by:
-
Ian Rogers authored
Break pmu-events test into 2 and add a test to verify that all pmu metric expressions simply parse. Try to parse all metric ids/events, skip/warn if metrics for the current architecture fail to parse. To support warning for a skip, and an ability for a subtest to describe why it skips. Tested on power9, skylakex, haswell, broadwell, westmere, sandybridge and ivybridge. May skip/warn on other architectures if metrics are invalid. In particular s390 is untested, but its expressions are trivial. The untested architectures with expressions are power8, cascadelakex, tremontx, skylake, jaketown, ivytown and variants of haswell and broadwell. v3. addresses review comments from John Garry <john.garry@huawei.com>, Jiri Olsa <jolsa@redhat.com> and Arnaldo Carvalho de Melo <acme@kernel.org>. v2. changes the commit message as event parsing errors no longer cause the test to fail. Committer notes: Check the return value of strtod() to fix the build in systems where that function is declared with attribute warn_unused_result. Signed-off-by:
-
Ian Rogers authored
Now subtests can inform why a test was skipped. The upcoming patch improvint PMU event metric testing will use it. Signed-off-by:
-
Ian Rogers authored
On a CPU like skylakex an uncore_iio_0 PMU may alias with uncore_iio_free_running_0. The latter PMU doesn't support fc_mask as a parameter and so pmu_config_term fails. Typically parse_events_add_pmu is called in a loop where if one alias succeeds errors are ignored, however, if multiple errors occur parse_events__handle_error will currently give a WARN_ONCE. This change removes the WARN_ONCE in parse_events__handle_error and makes it a pr_debug. It adds verbose messages to parse_events_add_pmu warning that non-fatal errors may occur, while giving details on the pmu and config terms for useful context. pmu_config_term is altered so the failing term and pmu are present in the case of the 'unknown term' error which makes spotting the free_running case more straightforward. Before: $ perf --debug verbose=3 stat -M llc_misses.pcie_read sleep 1 Using CPUID GenuineIntel-6-55-4 metric expr unc_iio_data_req_of_cpu.mem_read.part0 + unc_iio_data_req_of_cpu.mem_read.part1 + unc_iio_data_req_of_cpu.mem_read.part2 + unc_iio_data_req_of_cpu.mem_read.part3 for LLC_MISSES.PCIE_READ found event unc_iio_data_req_of_cpu.mem_read.part0 found event unc_iio_data_req_of_cpu.mem_read.part1 found event unc_iio_data_req_of_cpu.mem_read.part2 found event unc_iio_data_req_of_cpu.mem_read.part3 metric expr unc_iio_data_req_of_cpu.mem_read.part0 + unc_iio_data_req_of_cpu.mem_read.part1 + unc_iio_data_req_of_cpu.mem_read.part2 + unc_iio_data_req_of_cpu.mem_read.part3 for LLC_MISSES.PCIE_READ found event unc_iio_data_req_of_cpu.mem_read.part0 found event unc_iio_data_req_of_cpu.mem_read.part1 found event unc_iio_data_req_of_cpu.mem_read.part2 found event unc_iio_data_req_of_cpu.mem_read.part3 adding {unc_iio_data_req_of_cpu.mem_read.part0,unc_iio_data_req_of_cpu.mem_read.part1,unc_iio_data_req_of_cpu.mem_read.part2,unc_iio_data_req_of_cpu.mem_read.part3}:W,{unc_iio_data_req_of_cpu.mem_read.part0,unc_iio_data_req_of_cpu.mem_read.part1,unc_iio_data_req_of_cpu.mem_read.part2,unc_iio_data_req_of_cpu.mem_read.part3}:W intel_pt default config: tsc,mtc,mtc_period=3,psb_period=3,pt,branch WARNING: multiple event parsing errors ... Invalid event/parameter 'fc_mask' ... After: $ perf --debug verbose=3 stat -M llc_misses.pcie_read sleep 1 Using CPUID GenuineIntel-6-55-4 metric expr unc_iio_data_req_of_cpu.mem_read.part0 + unc_iio_data_req_of_cpu.mem_read.part1 + unc_iio_data_req_of_cpu.mem_read.part2 + unc_iio_data_req_of_cpu.mem_read.part3 for LLC_MISSES.PCIE_READ found event unc_iio_data_req_of_cpu.mem_read.part0 found event unc_iio_data_req_of_cpu.mem_read.part1 found event unc_iio_data_req_of_cpu.mem_read.part2 found event unc_iio_data_req_of_cpu.mem_read.part3 metric expr unc_iio_data_req_of_cpu.mem_read.part0 + unc_iio_data_req_of_cpu.mem_read.part1 + unc_iio_data_req_of_cpu.mem_read.part2 + unc_iio_data_req_of_cpu.mem_read.part3 for LLC_MISSES.PCIE_READ found event unc_iio_data_req_of_cpu.mem_read.part0 found event unc_iio_data_req_of_cpu.mem_read.part1 found event unc_iio_data_req_of_cpu.mem_read.part2 found event unc_iio_data_req_of_cpu.mem_read.part3 adding {unc_iio_data_req_of_cpu.mem_read.part0,unc_iio_data_req_of_cpu.mem_read.part1,unc_iio_data_req_of_cpu.mem_read.part2,unc_iio_data_req_of_cpu.mem_read.part3}:W,{unc_iio_data_req_of_cpu.mem_read.part0,unc_iio_data_req_of_cpu.mem_read.part1,unc_iio_data_req_of_cpu.mem_read.part2,unc_iio_data_req_of_cpu.mem_read.part3}:W intel_pt default config: tsc,mtc,mtc_period=3,psb_period=3,pt,branch Attempting to add event pmu 'uncore_iio_free_running_5' with 'unc_iio_data_req_of_cpu.mem_read.part0,' that may result in non-fatal errors After aliases, add event pmu 'uncore_iio_free_running_5' with 'fc_mask,ch_mask,umask,event,' that may result in non-fatal errors Attempting to add event pmu 'uncore_iio_free_running_3' with 'unc_iio_data_req_of_cpu.mem_read.part0,' that may result in non-fatal errors After aliases, add event pmu 'uncore_iio_free_running_3' with 'fc_mask,ch_mask,umask,event,' that may result in non-fatal errors Attempting to add event pmu 'uncore_iio_free_running_1' with 'unc_iio_data_req_of_cpu.mem_read.part0,' that may result in non-fatal errors After aliases, add event pmu 'uncore_iio_free_running_1' with 'fc_mask,ch_mask,umask,event,' that may result in non-fatal errors Multiple errors dropping message: unknown term 'fc_mask' for pmu 'uncore_iio_free_running_3' (valid terms: event,umask,config,config1,config2,name,period,percore) ... So before you see a 'WARNING: multiple event parsing errors' and 'Invalid event/parameter'. After you see 'Attempting... that may result in non-fatal errors' then 'Multiple errors...' with details that 'fc_mask' wasn't known to a free running counter. While not completely clean, this makes it clearer that an error hasn't really occurred. v2. addresses review feedback from Jiri Olsa <jolsa@redhat.com>. Signed-off-by:Andi Kleen <ak@linux.intel.com> Acked-by:
Jiri Olsa <jolsa@redhat.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: John Garry <john.garry@huawei.com> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Leo Yan <leo.yan@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lore.kernel.org/lkml/20200513220635.54700-1-irogers@google.comSigned-off-by:
-
Ian Rogers authored
Add a destructor for strings to reclaim memory in the event of errors. Free the ID given for a lookup, it was previously strdup-ed in the lex code. Signed-off-by:
-
Ravi Bangoria authored
Commit 7eec00a7 ("perf symbols: Consolidate symbol fixup issue") removed powerpc specific sym-handling.c file from Build. This wasn't caught by build CI because all functions in this file are declared as __weak in common code. Fix it. Fixes: 7eec00a7 ("perf symbols: Consolidate symbol fixup issue") Reported-by:
Sandipan Das <sandipan@linux.ibm.com> Signed-off-by:
Ravi Bangoria <ravi.bangoria@linux.ibm.com> Reviewed-by:
Leo Yan <leo.yan@linaro.org> Reviewed-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Acked-by:
-
Ian Rogers authored
Add test for fix in: commit 5741da3dee4c ("perf expr: Parse numbers as doubles") Signed-off-by: -
Anand K Mistry authored
The setting and checking of 'done' contains a rare race where the signal handler setting 'done' is run after checking to break the loop, but before waiting in evlist__poll(). In this case, the main loop won't wake up until either another signal is sent, or the perf data fd causes a wake up. The following simple script can trigger this condition (but you might need to run it for several hours): for ((i = 0; i >= 0; i++)) ; do echo "Loop $i" delay=$(echo "scale=4; 0.1 * $RANDOM/32768" | bc) ./perf record -- sleep 30000000 >/dev/null& pid=$! sleep $delay kill -TERM $pid echo "PID $pid" wait $pid done At some point, the loop will stall. Adding logging, even though perf has received the SIGTERM and set 'done = 1', perf will remain sleeping until a second signal is sent. Committer notes: Make this dependent on HAVE_EVENTFD_SUPPORT, so that we continue building on older systems without the eventfd syscall. Signed-off-by:
Anand K Mistry <amistry@google.com> Acked-by:
-
Arnaldo Carvalho de Melo authored
To be consistent with other such auto-detected features. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Anand K Mistry <amistry@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: -
Arnaldo Carvalho de Melo authored
Just like with the other fields, this probably isn't fixing anything observable as evsel__new() uses zalloc() for the whole 'struct evsel', but since evsels can be embedded in larger structures and maybe those larger structures don't use zalloc() for some reason, init it to NULL just in case. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Signed-off-by: -
Ian Rogers authored
If allocated, perf_pkg_mask and metric_events need freeing. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
When applying a patch by Ian I incorrectly converted to zfree() an expression that involved testing some other struct member, not the one being freed, which lead to bugs reproduceable by: $ perf stat -e i/bs,tsc,L2/o sleep 1 WARNING: multiple event parsing errors Segmentation fault (core dumped) $ Fix it by restoring the test for pos->free_str before freeing pos->val.str, but continue using zfree(&pos->val.str) to set that member to NULL after freeing it. Reported-by:
-
Jiri Olsa authored
Adrian reported that is_bpf_image is not working the way it was intended - passing on trampolines and dispatcher names. Instead it returned true for all the bpf names. The reason even this logic worked properly is that all bpf objects, even trampolines and dispatcher, were assigned DSO_BINARY_TYPE__BPF_IMAGE binary_type. The later for bpf_prog objects, the binary_type was fixed in bpf load event processing, which is executed after the ksymbol code. Fixing the is_bpf_image logic, so it properly recognizes trampoline and dispatcher objects. Fixes: 3c29d448 ("perf annotate: Add basic support for bpf_image") Reported-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Ian Rogers authored
When the event is passed as list, the default events should be listed as per 'perf mem record -e list'. Previous behavior is: $ perf c2c record -e list failed: event 'list' not found, use '-e list' to get list of available events Usage: perf c2c record [<options>] [<command>] or: perf c2c record [<options>] -- <command> [<options>] -e, --event <event> event selector. Use 'perf mem record -e list' to list available events $ New behavior: $ perf c2c record -e list ldlat-loads : available ldlat-stores : available v3: is a rebase. v2: addresses review comments by Jiri Olsa. https://lore.kernel.org/lkml/20191127081844.GH32367@krava/Signed-off-by: -
Paul A. Clarke authored
Add the following metrics to the POWER9 'cpi_breakdown' metricgroup: - ict_noslot_br_mpred_cpi - ict_noslot_br_mpred_icmiss_cpi - ict_noslot_cyc_other_cpi - ict_noslot_disp_held_cpi - ict_noslot_disp_held_hb_full_cpi - ict_noslot_disp_held_issq_cpi - ict_noslot_disp_held_other_cpi - ict_noslot_disp_held_sync_cpi - ict_noslot_disp_held_tbegin_cpi - ict_noslot_ic_l2_cpi - ict_noslot_ic_l3_cpi - ict_noslot_ic_l3miss_cpi - ict_noslot_ic_miss_cpi Signed-off-by:
Paul Clarke <pc@us.ibm.com> Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com> Reviewed-by:
Kajol Jain <kjain@linux.ibm.com> Tested-by:
-
Ian Rogers authored
During the processing of /proc during event synthesis new processes may start. Add a dummy event if /proc is to be processed, to capture mmaps for starting processes. This reuses the existing logic for initial-delay. v3 fixes the attr test of test-record-C0 v2 fixes the dummy event configuration and a branch stack issue. Suggested-by:
Stephane Eranian <eranian@google.com> Signed-off-by:
-
Ian Rogers authored
A dummy event never triggers any actual counter and therefore cannot be used with branch_stack Signed-off-by:
-
Jin Yao authored
A big uncore event group is split into multiple small groups which only include the uncore events from the same PMU. This has been supported in the commit 3cdc5c2c ("perf parse-events: Handle uncore event aliases in small groups properly"). If the event's PMU name starts to repeat, it must be a new event. That can be used to distinguish the leader from other members. But now it only compares the pointer of pmu_name (leader->pmu_name == evsel->pmu_name). If we use "perf stat -M LLC_MISSES.PCIE_WRITE -a" on cascadelakex, the event list is: evsel->name evsel->pmu_name --------------------------------------------------------------- unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_4 (as leader) unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_2 unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_0 unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_5 unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_3 unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_1 unc_iio_data_req_of_cpu.mem_write.part1 uncore_iio_4 ...... For the event "unc_iio_data_req_of_cpu.mem_write.part1" with "uncore_iio_4", it should be the event from PMU "uncore_iio_4". It's not a new leader for this PMU. But if we use "(leader->pmu_name == evsel->pmu_name)", the check would be failed and the event is stored to leaders[] as a new PMU leader. So this patch uses strcmp to compare the PMU name between events. Fixes: d4953f7e ("perf parse-events: Fix 3 use after frees found with clang ASAN") Signed-off-by:
Jin Yao <yao.jin@linux.intel.com> Acked-by:
-
Paul A. Clarke authored
Add another digit of precision to the perf metrics output. Before: $ /usr/bin/perf stat --metrics run_cpi /bin/ls [...] 4,345,526 pm_run_cyc # 1.1 run_cpi 3,818,069 pm_run_inst_cmpl [...] $ /usr/bin/perf stat --metrics run_cpi --metric-only /bin/ls [...] run_cpi 1.1 [...] After: $ perf stat --metrics run_cpi /bin/ls [...] 4,280,882 pm_run_cyc # 1.12 run_cpi 3,817,016 pm_run_inst_cmpl [...] $ perf stat --metrics run_cpi --metric-only /bin/ls [...] run_cpi 1.06 [...] Cc: Andi Kleen <ak@linux.intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Signed-off-by: -
Ian Rogers authored
If an expression yields 0 and is then divided-by/modulus-by then the parsing aborts. Add a debug error message to better enable debugging when this happens. Signed-off-by:
-
Ian Rogers authored
Mismatched parentheses. Fixes: 7f3cf5ac (perf vendor events power9: Cpi_breakdown & estimated_dcache_miss_cpi metrics) Signed-off-by:
-
Ian Rogers authored
Mismatched parentheses. Fixes: dd81eafa (perf vendor events power8: Cpi_breakdown & estimated_dcache_miss_cpi metrics) Signed-off-by:
-
Ian Rogers authored
Only effects parser debugging (disabled by default). Enables displaying '--accepting rule at line .. ("..."). Signed-off-by: -
Ian Rogers authored
This is expected in expr.y and metrics use floating point values such as x86 broadwell IFetch_Line_Utilization. Fixes: 26226a97 (perf expr: Move expr lexer to flex) Signed-off-by:
-
Ian Rogers authored
Large metrics such as Branch_Misprediction_Cost_SMT on x86 broadwell need more space. Signed-off-by:
-
Ian Rogers authored
Corrects parse errors in expr__find_other of expressions with min. Signed-off-by:
-
Ian Rogers authored
Remove over escaping with \\. Fixes: fd550098 (perf vendor events intel: Update metrics from TMAM 3.5) Signed-off-by:
-
Ian Rogers authored
Remove over escaping with \\. Remove extraneous if 1 if 0 == 1 else 0 else 0. Fixes: fd550098 (perf vendor events intel: Update metrics from TMAM 3.5) Signed-off-by:
-
Ian Rogers authored
Current expression allows 2 escaped '-,=' characters. However, some metrics require more, for example Haswell DRAM_BW_Use. Fixes: 26226a97 (perf expr: Move expr lexer to flex) Signed-off-by:
-
Jiri Olsa authored
In case the callchains were deleted in pipe mode, we need to ensure that the IP fields are enabled, otherwise the callchain is not displayed. Enabling IP and SYM, which should be enough for callchains. Committer testing: Before: Committer Testing: before: # ls # perf record -g -e 'syscalls:*' sleep 0.1 2>/dev/null | perf script | tail sleep 5677 [0] 5034.295882: syscalls:sys_exit_mmap: 0x7fcbcfa74000 sleep 5677 [0] 5034.295885: syscalls:sys_enter_close: fd: 0x00000003 sleep 5677 [0] 5034.295886: syscalls:sys_exit_close: 0x0 sleep 5677 [0] 5034.295911: syscalls:sys_enter_nanosleep: rqtp: 0x7fff775b33a0, rmtp: 0x00000000 sleep 5677 [0] 5034.396021: syscalls:sys_exit_nanosleep: 0x0 sleep 5677 [0] 5034.396027: syscalls:sys_enter_close: fd: 0x00000001 sleep 5677 [0] 5034.396028: syscalls:sys_exit_close: 0x0 sleep 5677 [0] 5034.396029: syscalls:sys_enter_close: fd: 0x00000002 sleep 5677 [0] 5034.396029: syscalls:sys_exit_close: 0x0 sleep 5677 [0] 5034.396032: syscalls:sys_enter_exit_group: error_code: 0x00000000 # # ls # After: # perf record --call-graph=dwarf -e 'syscalls:sys_enter*' sleep 0.1 2>/dev/null | perf script | tail -37 sleep 33010 [000] 5400.625269: syscalls:sys_enter_nanosleep: rqtp: 0x7fff2d0e7860, rmtp: 0x00000000 7f1406f131a7 __GI___nanosleep (inlined) 561c4f996966 [unknown] 561c4f99673f [unknown] 561c4f9937af [unknown] 7f1406e6c1a2 __libc_start_main 561c4f99388d [unknown] sleep 33010 [000] 5400.725391: syscalls:sys_enter_close: fd: 0x00000001 7f1406f3c3cb __GI___close_nocancel (inlined) 7f1406ec7d6f _IO_new_file_close_it (inlined) 7f1406ebafa5 _IO_new_fclose (inlined) 561c4f996a40 [unknown] 561c4f993d79 [unknown] 7f1406e83e86 __run_exit_handlers 7f1406e8403f __GI_exit (inlined) 7f1406e6c1a9 __libc_start_main 561c4f99388d [unknown] sleep 33010 [000] 5400.725395: syscalls:sys_enter_close: fd: 0x00000002 7f1406f3c3cb __GI___close_nocancel (inlined) 7f1406ec7d6f _IO_new_file_close_it (inlined) 7f1406ebafa5 _IO_new_fclose (inlined) 561c4f996a40 [unknown] 561c4f993da2 [unknown] 7f1406e83e86 __run_exit_handlers 7f1406e8403f __GI_exit (inlined) 7f1406e6c1a9 __libc_start_main 561c4f99388d [unknown] sleep 33010 [000] 5400.725399: syscalls:sys_enter_exit_group: error_code: 0x00000000 7f1406f13466 __GI__exit (inlined) 7f1406e83fa1 __run_exit_handlers 7f1406e8403f __GI_exit (inlined) 7f1406e6c1a9 __libc_start_main 561c4f99388d [unknown] # And, if we install coreutils-debuginfo, we'll have those [unknown] resolved, those are for the /usr/bin/sleep binary, use: # dnf debuginfo-install coreutils On Fedora and derivatives, then: # perf record --call-graph=dwarf -e 'syscalls:sys_enter*' sleep 0.1 2>/dev/null | perf script | tail -37 sleep 33046 [009] 5533.910074: syscalls:sys_enter_nanosleep: rqtp: 0x7ffea6fa7ab0, rmtp: 0x00000000 7f5f786e81a7 __GI___nanosleep (inlined) 564472454966 rpl_nanosleep 56447245473f xnanosleep 5644724517af main 7f5f786411a2 __libc_start_main 56447245188d _start sleep 33046 [009] 5534.010218: syscalls:sys_enter_close: fd: 0x00000001 7f5f787113cb __GI___close_nocancel (inlined) 7f5f7869cd6f _IO_new_file_close_it (inlined) 7f5f7868ffa5 _IO_new_fclose (inlined) 564472454a40 close_stream 564472451d79 close_stdout 7f5f78658e86 __run_exit_handlers 7f5f7865903f __GI_exit (inlined) 7f5f786411a9 __libc_start_main 56447245188d _start sleep 33046 [009] 5534.010224: syscalls:sys_enter_close: fd: 0x00000002 7f5f787113cb __GI___close_nocancel (inlined) 7f5f7869cd6f _IO_new_file_close_it (inlined) 7f5f7868ffa5 _IO_new_fclose (inlined) 564472454a40 close_stream 564472451da2 close_stdout 7f5f78658e86 __run_exit_handlers 7f5f7865903f __GI_exit (inlined) 7f5f786411a9 __libc_start_main 56447245188d _start sleep 33046 [009] 5534.010229: syscalls:sys_enter_exit_group: error_code: 0x00000000 7f5f786e8466 __GI__exit (inlined) 7f5f78658fa1 __run_exit_handlers 7f5f7865903f __GI_exit (inlined) 7f5f786411a9 __libc_start_main 56447245188d _start # Reported-by:Paul Khuong <pvk@pvk.ca> Signed-off-by:
-
Jiri Olsa authored
Callchains are automatically initialized by checking on event's sample_type. For pipe mode we need to put this check into attr event code. Moving the callchains setup code into callchain_param_setup function and calling it from attr event process code. This enables pipe output having callchains, like: # perf record -g -e 'raw_syscalls:sys_enter' true | perf script # perf record -g -e 'raw_syscalls:sys_enter' true | perf report Committer notes: We still need the next patch for the above output to work. Reported-by:
-
Jiri Olsa authored
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<blink::AllElementsSelectorQueryTrait> 2.25% chromium libblink_core.so [.] blink::SelectorQuery::FindTraverseRootsAndExecute<blink::AllElementsSelectorQueryTrait> 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: -
Jiri Olsa authored
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 authored
Even with fully built tree, we still display extra output when make is invoked, like: $ make BUILD: Doing 'make -j8' parallel build DESCEND plugins make[3]: Nothing to be done for 'plugins/libtraceevent-dynamic-list'. Changing the make descend directly to plugins directory, which quiets those messages down. Reported-by: -
Masami Hiramatsu authored
When a probe point is expanded to several places (like inlined) and if some of them are skipped because of blacklisted or __init function, those trace_events has no event name. It must be skipped while showing results. Without this fix, you can see "(null):(null)" on the list, # ./perf probe request_resource reserve_setup is out of .text, skip it. Added new events: (null):(null) (on request_resource) probe:request_resource (on request_resource) You can now use it in all perf tools, such as: perf record -e probe:request_resource -aR sleep 1 # With this fix, it is ignored: # ./perf probe request_resource reserve_setup is out of .text, skip it. Added new events: probe:request_resource (on request_resource) You can now use it in all perf tools, such as: perf record -e probe:request_resource -aR sleep 1 # Fixes: 5a51fcd1 ("perf probe: Skip kernel symbols which is out of .text") Signed-off-by:Masami Hiramatsu <mhiramat@kernel.org> Tested-by:
-
Masami Hiramatsu authored
Since commit 03db8b58 ("perf tools: Fix maps__find_symbol_by_name()") introduced map address range check in maps__find_symbol_by_name(), we can not get "_etext" from kernel map because _etext is placed on the edge of the kernel .text section (= kernel map in perf.) To fix this issue, this checks the address correctness by map address range information (map->start and map->end) instead of using _etext address. This can cause an error if the target inlined function is embedded in both __init function and normal function. For exaample, request_resource() is a normal function but also embedded in __init reserve_setup(). In this case, the probe point in reserve_setup() must be skipped. However, without this fix, it failes to setup all probe points: # ./perf probe -v request_resource probe-definition(0): request_resource symbol:request_resource file:(null) line:0 offset:0 return:0 lazy:(null) 0 arguments Looking at the vmlinux_path (8 entries long) Using /usr/lib/debug/lib/modules/5.5.17-200.fc31.x86_64/vmlinux for symbols Open Debuginfo file: /usr/lib/debug/lib/modules/5.5.17-200.fc31.x86_64/vmlinux Try to find probe point from debuginfo. Matched function: request_resource [15e29ad] found inline addr: 0xffffffff82fbf892 Probe point found: reserve_setup+204 found inline addr: 0xffffffff810e9790 Probe point found: request_resource+0 Found 2 probe_trace_events. Opening /sys/kernel/debug/tracing//kprobe_events write=1 Opening /sys/kernel/debug/tracing//README write=0 Writing event: p:probe/request_resource _text+33290386 Failed to write event: Invalid argument Error: Failed to add events. Reason: Invalid argument (Code: -22) # With this fix, # ./perf probe request_resource reserve_setup is out of .text, skip it. Added new events: (null):(null) (on request_resource) probe:request_resource (on request_resource) You can now use it in all perf tools, such as: perf record -e probe:request_resource -aR sleep 1 # Fixes: 03db8b58 ("perf tools: Fix maps__find_symbol_by_name()") Reported-by:
Arnaldo Carvalho de Melo <acme@kernel.org> Signed-off-by:
-
