summaryrefslogtreecommitdiff
path: root/tools/perf
AgeCommit message (Collapse)Author
2025-04-10perf ui browser: Accept the left arrow key as a Zoom out if done on the ↵Arnaldo Carvalho de Melo
first column In the past (like before 2015) we had the familiar workflow of using ENTER to get the menu and then zoom on a pid or DSO, kernel, etc and then use UP and DOWN to navigate further, etc, and then when wanting to go to the previous level, i.e. to Zoom out, use the LEFT arrow key. This way the right hand stays in the arrow keys block that is near the enter and we can go around real quickly. But then, when we started supporting horizontal scrolling by columns to support things like 'perf c2c report' that has lots of columns, we switched to using the LEFT key exclusively for that, horizontal scrolling, requiring the user to press 'm' to get a "context menu" that then would allow users to select the Zoom out operation. Ingo recently reported this as not intuitive, which is true, so lets overload the LEFT key with both meanings, by doing a Zoom out operation if the LEFT key is pressed when we're on the first column, but use it also for horizontal scrolling if it is pressed when the cursor is on column > 1. Reported-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/Z_TYux5fUg2pW-pF@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10perf ui browser annotate: Don't show the source code view status initiallyArnaldo Carvalho de Melo
To avoid initial clutter, and not to change the view users that are not interested in toggling the source code view, just show it when the user does the first toggle keypress (pressing 's'). I know that there are users that really disable the source code view by using: # perf config annotate.hide_src_code=yes Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/Z_TYux5fUg2pW-pF@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10perf ui browser annotate: Show in the title the source code view toggleArnaldo Carvalho de Melo
Ingo reported that having a visual cue if the source code view is enabled will help in noticing a bug when no source is presented. Change the title scnprintf routine for the annotation browser to do that. More work is needed to have the capabilities of the existing disassemblers listed somehow and start using the fastest one but switch to another that provides features only made available by some particular one, like the first one, the objdump output parsing one. Suggested-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/Z_TYux5fUg2pW-pF@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10perf ui browser map: Provide feedback on unhandled hotkeysArnaldo Carvalho de Melo
Don't just eat unknown keys without providing visual feedback and instructions on how to see which ones are assigned. Suggested-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/Z_TYux5fUg2pW-pF@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10perf ui browser hists: Provide feedback on unhandled hotkeysArnaldo Carvalho de Melo
Don't just eat unknown keys without providing visual feedback and instructions on how to see which ones are assigned. Suggested-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/Z_TYux5fUg2pW-pF@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10perf ui browser header: Provide feedback on unhandled hotkeysArnaldo Carvalho de Melo
Don't just eat unknown keys without providing visual feedback and instructions on how to see which ones are assigned. Suggested-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/Z_TYux5fUg2pW-pF@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10perf ui browser annotate: Provide feedback on unhandled hotkeysArnaldo Carvalho de Melo
Don't just eat unknown keys without providing visual feedback and instructions on how to see which ones are assigned. Suggested-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/Z_TYux5fUg2pW-pF@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10perf ui browser annotate-data: Provide feedback on unhandled hotkeysArnaldo Carvalho de Melo
Don't just eat unknown keys without providing visual feedback and instructions on how to see which ones are assigned. Suggested-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/Z_TYux5fUg2pW-pF@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10perf ui browser: Add a warn on unhandled hotkey helperArnaldo Carvalho de Melo
Will be used by the various browsers, looks like: ┌─Warning!───────────────────────────────────────────┐ 29.15 │ 3c: cmpl $0x3,(%rbx) │ │ 3.77 │ ↓ je 51 │'Ctrl+V' key not associated, use 'h' to see actions!│ 16.59 │ movq 0x3b0(%rbx),%rdx │ │ 30.65 │ movl 0x8(%rdx),%eax │ │ 3.77 │ cmpl %eax,%edi │Press any key... │ 0.25 │ ↓ jb 82 └────────────────────────────────────────────────────┘ Suggested-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/Z_TYux5fUg2pW-pF@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10perf ui browser: Add key_name() helperArnaldo Carvalho de Melo
We'll use it to show unhandled keys in the various TUI browsers. Suggested-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/Z_TYux5fUg2pW-pF@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10perf check: Add tip about building with libbfd using BUILD_NONDISTRO=1Arnaldo Carvalho de Melo
There are still some cases, for instance to disassembly BPF code that needs this, so until someone works on supporting that, we're keeping the code but it is opt-in. Make that clear on the 'perf version --build-options' and other ways to query if a feature is present: $ perf check feature libbfd libbfd: [ OFF ] # HAVE_LIBBFD_SUPPORT ( tip: Deprecated, license incompatibility, use BUILD_NONDISTRO=1 and install binutils-dev[el] ) $ perf -vv | grep bfd libbfd: [ OFF ] # HAVE_LIBBFD_SUPPORT ( tip: Deprecated, license incompatibility, use BUILD_NONDISTRO=1 and install binutils-dev[el] ) $ Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Dmitriy Vyukov <dvyukov@google.com> Cc: Howard Chu <howardchu95@gmail.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/Z_dkNDj9EPFwPqq1@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10perf build: Warn when libdebuginfod devel files are not availableArnaldo Carvalho de Melo
While working on 'perf version --build-options' I noticed that: $ perf version --build-options perf version 6.15.rc1.g312a07a00d31 aio: [ on ] # HAVE_AIO_SUPPORT bpf: [ on ] # HAVE_LIBBPF_SUPPORT bpf_skeletons: [ on ] # HAVE_BPF_SKEL debuginfod: [ OFF ] # HAVE_DEBUGINFOD_SUPPORT <SNIP> And looking at tools/perf/Makefile.config I also noticed that it is not opt-in, meaning we will attempt to build with it in all normal cases. So add the usual warning at build time to let the user know that something recommended is missing, now we see: Makefile.config:563: No elfutils/debuginfod.h found, no debuginfo server support, please install elfutils-debuginfod-client-devel or equivalent And after following the recommendation: $ perf check feature debuginfod debuginfod: [ on ] # HAVE_DEBUGINFOD_SUPPORT $ ldd ~/bin/perf | grep debuginfo libdebuginfod.so.1 => /lib64/libdebuginfod.so.1 (0x00007fee5cf5f000) $ With this feature on several perf tools will fetch what is needed and not require all the contents of the debuginfo packages, for instance: # rpm -qa | grep kernel-debuginfo # pahole --running_kernel_vmlinux pahole: couldn't find a vmlinux that matches the running kernel HINT: Maybe you're inside a container or missing a debuginfo package? # # perf trace -e open* perf probe --vars icmp_rcv 0.000 ( 0.005 ms): perf/97391 openat(dfd: CWD, filename: "/etc/ld.so.cache", flags: RDONLY|CLOEXEC) = 3 0.014 ( 0.004 ms): perf/97391 openat(dfd: CWD, filename: "/lib64/libm.so.6", flags: RDONLY|CLOEXEC) = 3 <SNIP> 32130.100 ( 0.008 ms): perf/97391 openat(dfd: CWD, filename: "/root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo") = 3 <SNIP> Available variables at icmp_rcv @<icmp_rcv+0> struct sk_buff* skb <SNIP> # # pahole --running_kernel_vmlinux /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo # file /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=aa3c82b4a13f9c0e0301bebb20fe958c4db6f362, with debug_info, not stripped # ls -la /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo -r--------. 1 root root 475401512 Mar 27 21:00 /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo # Then, cached: # perf stat --null perf probe --vars icmp_rcv Available variables at icmp_rcv @<icmp_rcv+0> struct sk_buff* skb Performance counter stats for 'perf probe --vars icmp_rcv': 0.671389041 seconds time elapsed 0.519176000 seconds user 0.150860000 seconds sys Fixes: c7a14fdcb3fa7736 ("perf build-ids: Fall back to debuginfod query if debuginfo not found") Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Dmitriy Vyukov <dvyukov@google.com> Cc: Howard Chu <howardchu95@gmail.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Frank Ch. Eigler <fche@redhat.com> Link: https://lore.kernel.org/r/Z_dkNDj9EPFwPqq1@gmail.com [ Folded patch from Ingo to have the debian/ubuntu devel package added build warning message ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10perf check: Allow showing a tip for opt-in features not built into perfArnaldo Carvalho de Melo
Ingo reported that it was difficult to understand why libunwind support didn't link even when he had the usual libunwind-dev files installed in his machine. This is because libunwind became opt-in, the user has to use LIBUNWIND=1, as it was deemed stalled in its development/unsuitable for use with perf, IIRC, and so we better use the elfutils equivalent routine that we also supported for ages. But the build message still printed: Auto-detecting system features: ... libdw: [ on ] ... glibc: [ on ] <SNIP> ... libcrypto: [ on ] ... libunwind: [ OFF ] <SNIP> Which is confusing, so allow for having a tip when 'perf version --build-options' is used, and variants with 'perf check feature': $ perf version --build-options | grep libunwind libunwind: [ OFF ] # HAVE_LIBUNWIND_SUPPORT ( tip: Deprecated, use LIBUNWIND=1 and install libunwind-dev[el] to build with it ) $ $ perf check feature libunwind libunwind: [ OFF ] # HAVE_LIBUNWIND_SUPPORT ( tip: Deprecated, use LIBUNWIND=1 and install libunwind-dev[el] to build with it ) $ The next patches will remove the opt-in libunwind FEATURES_DISPLAY. Reported-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Dmitriy Vyukov <dvyukov@google.com> Cc: Howard Chu <howardchu95@gmail.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/Z--pWmTHGb62_83e@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10perf check: Move the FEATURE_STATUS() macro to its only user source fileArnaldo Carvalho de Melo
It is just 'perf check' that uses that macro, to initialize the list of features built into perf, so move it there. This also avoids depending on things that are not included from builtin.h, like is_builtin(), the CONFIG_ macros, etc, that are all included in 'builtin-check.c' and before where this macro was moved to. Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Dmitriy Vyukov <dvyukov@google.com> Cc: Howard Chu <howardchu95@gmail.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/Z_dkNDj9EPFwPqq1@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10perf check: Share the feature status printing routine with 'perf version'Arnaldo Carvalho de Melo
Both had the same open coded functions, share them so that we can add tips for opt-in features such as libunwind, coresight, etc. Examples of use: $ perf check feature libcapstone libcapstone: [ on ] # HAVE_LIBCAPSTONE_SUPPORT $ perf check feature libunwind libunwind: [ OFF ] # HAVE_LIBUNWIND_SUPPORT $ perf version --build-options perf version 6.15.rc1.g113e3df8ccc5 aio: [ on ] # HAVE_AIO_SUPPORT bpf: [ on ] # HAVE_LIBBPF_SUPPORT bpf_skeletons: [ on ] # HAVE_BPF_SKEL debuginfod: [ OFF ] # HAVE_DEBUGINFOD_SUPPORT dwarf: [ on ] # HAVE_LIBDW_SUPPORT dwarf_getlocations: [ on ] # HAVE_LIBDW_SUPPORT dwarf-unwind: [ on ] # HAVE_DWARF_UNWIND_SUPPORT auxtrace: [ on ] # HAVE_AUXTRACE_SUPPORT libbfd: [ OFF ] # HAVE_LIBBFD_SUPPORT libcapstone: [ on ] # HAVE_LIBCAPSTONE_SUPPORT libcrypto: [ on ] # HAVE_LIBCRYPTO_SUPPORT libdw-dwarf-unwind: [ on ] # HAVE_LIBDW_SUPPORT libelf: [ on ] # HAVE_LIBELF_SUPPORT libnuma: [ on ] # HAVE_LIBNUMA_SUPPORT libopencsd: [ on ] # HAVE_CSTRACE_SUPPORT libperl: [ on ] # HAVE_LIBPERL_SUPPORT libpfm4: [ on ] # HAVE_LIBPFM libpython: [ on ] # HAVE_LIBPYTHON_SUPPORT libslang: [ on ] # HAVE_SLANG_SUPPORT libtraceevent: [ on ] # HAVE_LIBTRACEEVENT libunwind: [ OFF ] # HAVE_LIBUNWIND_SUPPORT lzma: [ on ] # HAVE_LZMA_SUPPORT numa_num_possible_cpus: [ on ] # HAVE_LIBNUMA_SUPPORT zlib: [ on ] # HAVE_ZLIB_SUPPORT zstd: [ on ] # HAVE_ZSTD_SUPPORT $ Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Dmitriy Vyukov <dvyukov@google.com> Cc: Howard Chu <howardchu95@gmail.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/Z_Rz10stoLzBocIO@x1 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-10tools build: Don't set libunwind as available if test-all.c build succeedsArnaldo Carvalho de Melo
The tools/build/feature/test-all.c file tries to detect the expected, most common set of libraries/features we expect to have available to build perf with. At some point libunwind was deemed not to be part of that set of libries, but the patches making it to be opt-in ended up forgetting some details, fix one more. Testing it: $ rm -rf /tmp/build/$(basename $PWD)/ ; mkdir -p /tmp/build/$(basename $PWD)/ $ rpm -q libunwind-devel libunwind-devel-1.8.0-3.fc40.x86_64 $ make -k LIBUNWIND=1 CORESIGHT=1 O=/tmp/build/$(basename $PWD)/ -C tools/perf install-bin |& grep unwind && ldd ~/bin/perf | grep unwind ... libunwind: [ on ] CC /tmp/build/perf-tools-next/arch/x86/tests/dwarf-unwind.o CC /tmp/build/perf-tools-next/arch/x86/util/unwind-libunwind.o CC /tmp/build/perf-tools-next/util/arm64-frame-pointer-unwind-support.o CC /tmp/build/perf-tools-next/tests/dwarf-unwind.o CC /tmp/build/perf-tools-next/util/unwind-libunwind-local.o CC /tmp/build/perf-tools-next/util/unwind-libunwind.o libunwind-x86_64.so.8 => /lib64/libunwind-x86_64.so.8 (0x00007f615a549000) libunwind.so.8 => /lib64/libunwind.so.8 (0x00007f615a52f000) $ sudo rpm -e libunwind-devel $ rm -rf /tmp/build/$(basename $PWD)/ ; mkdir -p /tmp/build/$(basename $PWD)/ $ make -k LIBUNWIND=1 CORESIGHT=1 O=/tmp/build/$(basename $PWD)/ -C tools/perf install-bin |& grep unwind && ldd ~/bin/perf | grep unwind Makefile.config:653: No libunwind found. Please install libunwind-dev[el] >= 1.1 and/or set LIBUNWIND_DIR ... libunwind: [ OFF ] CC /tmp/build/perf-tools-next/arch/x86/tests/dwarf-unwind.o CC /tmp/build/perf-tools-next/arch/x86/util/unwind-libdw.o CC /tmp/build/perf-tools-next/util/arm64-frame-pointer-unwind-support.o CC /tmp/build/perf-tools-next/tests/dwarf-unwind.o CC /tmp/build/perf-tools-next/util/unwind-libdw.o $ Should be in a separate patch, but tired now, so also adding a message about the need to use LIBUNWIND=1 in the output when its not available, so done here as well. So, now when the devel files are not available we get: $ make -k LIBUNWIND=1 CORESIGHT=1 O=/tmp/build/$(basename $PWD)/ -C tools/perf install-bin |& grep unwind && ldd ~/bin/perf | grep unwind Makefile.config:653: No libunwind found. Please install libunwind-dev[el] >= 1.1 and/or set LIBUNWIND_DIR and set LIBUNWIND=1 in the make command line as it is opt-in now ... libunwind: [ OFF ] $ Fixes: 13e17c9ff49119aa ("perf build: Make libunwind opt-in rather than opt-out") Reported-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Dmitriy Vyukov <dvyukov@google.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/Z_AnsW9oJzFbhIFC@x1 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2025-04-05tracing/timers: Rename the hrtimer_init event to hrtimer_setupNam Cao
The function hrtimer_init() doesn't exist anymore. It was replaced by hrtimer_setup(). Thus, rename the hrtimer_init trace event to hrtimer_setup to keep it consistent. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/all/cba84c3d853c5258aa3a262363a6eac08e2c7afc.1738746927.git.namcao@linutronix.de
2025-03-31Merge tag 'perf-tools-for-v6.15-2025-03-27' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools Pull perf tools updates from Namhyung Kim: "perf record: - Introduce latency profiling using scheduler information. The latency profiling is to show impacts on wall-time rather than cpu-time. By tracking context switches, it can weight samples and find which part of the code contributed more to the execution latency. The value (period) of the sample is weighted by dividing it by the number of parallel execution at the moment. The parallelism is tracked in perf report with sched-switch records. This will reduce the portion that are run in parallel and in turn increase the portion of serial executions. For now, it's limited to profile processes, IOW system-wide profiling is not supported. You can add --latency option to enable this. $ perf record --latency -- make -C tools/perf I've run the above command for perf build which adds -j option to make with the number of CPUs in the system internally. Normally it'd show something like below: $ perf report -F overhead,comm ... # # Overhead Command # ........ ............... # 78.97% cc1 6.54% python3 4.21% shellcheck 3.28% ld 1.80% as 1.37% cc1plus 0.80% sh 0.62% clang 0.56% gcc 0.44% perl 0.39% make ... The cc1 takes around 80% of the overhead as it's the actual compiler. However it runs in parallel so its contribution to latency may be less than that. Now, perf report will show both overhead and latency (if --latency was given at record time) like below: $ perf report -s comm ... # # Overhead Latency Command # ........ ........ ............... # 78.97% 48.66% cc1 6.54% 25.68% python3 4.21% 0.39% shellcheck 3.28% 13.70% ld 1.80% 2.56% as 1.37% 3.08% cc1plus 0.80% 0.98% sh 0.62% 0.61% clang 0.56% 0.33% gcc 0.44% 1.71% perl 0.39% 0.83% make ... You can see latency of cc1 goes down to around 50% and python3 and ld contribute a lot more than their overhead. You can use --latency option in perf report to get the same result but ordered by latency. $ perf report --latency -s comm perf report: - As a side effect of the latency profiling work, it adds a new output field 'latency' and a sort key 'parallelism'. The below is a result from my system with 64 CPUs. The build was well-parallelized but contained some serial portions. $ perf report -s parallelism ... # # Overhead Latency Parallelism # ........ ........ ........... # 16.95% 1.54% 62 13.38% 1.24% 61 12.50% 70.47% 1 11.81% 1.06% 63 7.59% 0.71% 60 4.33% 12.20% 2 3.41% 0.33% 59 2.05% 0.18% 64 1.75% 1.09% 9 1.64% 1.85% 5 ... - Support Feodra mini-debuginfo which is a LZMA compressed symbol table inside ".gnu_debugdata" ELF section. perf annotate: - Add --code-with-type option to enable data-type profiling with the usual annotate output. Instead of focusing on data structure, it shows code annotation together with data type it accesses in case the instruction refers to a memory location (and it was able to resolve the target data type). Currently it only works with --stdio. $ perf annotate --stdio --code-with-type ... Percent | Source code & Disassembly of vmlinux for cpu/mem-loads,ldlat=30/pp (18 samples, percent: local period) ---------------------------------------------------------------------------------------------------------------------- : 0 0xffffffff81050610 <__fdget>: 0.00 : ffffffff81050610: callq 0xffffffff81c01b80 <__fentry__> # data-type: (stack operation) 0.00 : ffffffff81050615: pushq %rbp # data-type: (stack operation) 0.00 : ffffffff81050616: movq %rsp, %rbp 0.00 : ffffffff81050619: pushq %r15 # data-type: (stack operation) 0.00 : ffffffff8105061b: pushq %r14 # data-type: (stack operation) 0.00 : ffffffff8105061d: pushq %rbx # data-type: (stack operation) 0.00 : ffffffff8105061e: subq $0x10, %rsp 0.00 : ffffffff81050622: movl %edi, %ebx 0.00 : ffffffff81050624: movq %gs:0x7efc4814(%rip), %rax # 0x14e40 <current_task> # data-type: struct task_struct* +0 0.00 : ffffffff8105062c: movq 0x8d0(%rax), %r14 # data-type: struct task_struct +0x8d0 (files) 0.00 : ffffffff81050633: movl (%r14), %eax # data-type: struct files_struct +0 (count.counter) 0.00 : ffffffff81050636: cmpl $0x1, %eax 0.00 : ffffffff81050639: je 0xffffffff810506a9 <__fdget+0x99> 0.00 : ffffffff8105063b: movq 0x20(%r14), %rcx # data-type: struct files_struct +0x20 (fdt) 0.00 : ffffffff8105063f: movl (%rcx), %eax # data-type: struct fdtable +0 (max_fds) 0.00 : ffffffff81050641: cmpl %ebx, %eax 0.00 : ffffffff81050643: jbe 0xffffffff810506ef <__fdget+0xdf> 0.00 : ffffffff81050649: movl %ebx, %r15d 5.56 : ffffffff8105064c: movq 0x8(%rcx), %rdx # data-type: struct fdtable +0x8 (fd) ... The "# data-type:" part was added with this change. The first few entries are not very interesting. But later you can it accesses a couple of fields in the task_struct, files_struct and fdtable. perf trace: - Support syscall tracing for different ABI. For example it can trace system calls for 32-bit applications on 64-bit kernel transparently. - Add --summary-mode=total option to show global syscall summary. The default is 'thread' to show per-thread syscall summary. Python support: - Add more interfaces to 'perf' module to parse events, and config, enable or disable the event list properly so that it can implement basic functionalities purely in Python. There is an example code for these new interfaces in python/tracepoint.py. - Add mypy and pylint support to enable build time checking. Fix some code based on the findings from these tools. Internals: - Introduce io_dir__readdir() API to make directory traveral (usually for proc or sysfs) efficient with less memory footprint. JSON vendor events: - Add events and metrics for ARM Neoverse N3 and V3 - Update events and metrics on various Intel CPUs - Add/update events for a number of SiFive processors" * tag 'perf-tools-for-v6.15-2025-03-27' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: (229 commits) perf bpf-filter: Fix a parsing error with comma perf report: Fix a memory leak for perf_env on AMD perf trace: Fix wrong size to bpf_map__update_elem call perf tools: annotate asm_pure_loop.S perf python: Fix setup.py mypy errors perf test: Address attr.py mypy error perf build: Add pylint build tests perf build: Add mypy build tests perf build: Rename TEST_LOGS to SHELL_TEST_LOGS tools/build: Don't pass test log files to linker perf bench sched pipe: fix enforced blocking reads in worker_thread perf tools: Fix is_compat_mode build break in ppc64 perf build: filter all combinations of -flto for libperl perf vendor events arm64 AmpereOneX: Fix frontend_bound calculation perf vendor events arm64: AmpereOne/AmpereOneX: Mark LD_RETIRED impacted by errata perf trace: Fix evlist memory leak perf trace: Fix BTF memory leak perf trace: Make syscall table stable perf syscalltbl: Mask off ABI type for MIPS system calls perf build: Remove Makefile.syscalls ...
2025-03-24perf bpf-filter: Fix a parsing error with commaNamhyung Kim
The previous change to support cgroup filters introduced a bug that pathname can include commas. It confused the lexer to treat an item and the trailing comma as a single token. And it resulted in a parse error: $ sudo perf record -e cycles:P --filter 'period > 0, ip > 64' -- true perf_bpf_filter: Error: Unexpected item: 0, perf_bpf_filter: syntax error, unexpected BFT_ERROR, expecting BFT_NUM Usage: perf record [<options>] [<command>] or: perf record [<options>] -- <command> [<options>] --filter <filter> event filter It should get "0" and "," separately. An easiest fix would be to remove "," from the possible pathname characters. As it's for cgroup names, probably ok to assume it won't have commas in the pathname. I found that the existing BPF filtering test didn't have any complex filter condition with commas. Let's update the group filter test which is supposed to test filter combinations like this. Link: https://lore.kernel.org/r/20250307220922.434319-1-namhyung@kernel.org Fixes: 91e88437d5156b20 ("perf bpf-filter: Support filtering on cgroups") Reported-by: Sally Shi <sshii@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-24perf report: Fix a memory leak for perf_env on AMDNamhyung Kim
The env.pmu_mapping can be leaked when it reads data from a pipe on AMD. For a pipe data, it reads the header data including pmu_mapping from PERF_RECORD_HEADER_FEATURE runtime. But it's already set in: perf_session__new() __perf_session__new() evlist__init_trace_event_sample_raw() evlist__has_amd_ibs() perf_env__nr_pmu_mappings() Then it'll overwrite that when it processes the HEADER_FEATURE record. Here's a report from address sanitizer. Direct leak of 2689 byte(s) in 1 object(s) allocated from: #0 0x7fed8f814596 in realloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:98 #1 0x5595a7d416b1 in strbuf_grow util/strbuf.c:64 #2 0x5595a7d414ef in strbuf_init util/strbuf.c:25 #3 0x5595a7d0f4b7 in perf_env__read_pmu_mappings util/env.c:362 #4 0x5595a7d12ab7 in perf_env__nr_pmu_mappings util/env.c:517 #5 0x5595a7d89d2f in evlist__has_amd_ibs util/amd-sample-raw.c:315 #6 0x5595a7d87fb2 in evlist__init_trace_event_sample_raw util/sample-raw.c:23 #7 0x5595a7d7f893 in __perf_session__new util/session.c:179 #8 0x5595a7b79572 in perf_session__new util/session.h:115 #9 0x5595a7b7e9dc in cmd_report builtin-report.c:1603 #10 0x5595a7c019eb in run_builtin perf.c:351 #11 0x5595a7c01c92 in handle_internal_command perf.c:404 #12 0x5595a7c01deb in run_argv perf.c:448 #13 0x5595a7c02134 in main perf.c:556 #14 0x7fed85833d67 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Let's free the existing pmu_mapping data if any. Cc: Ravi Bangoria <ravi.bangoria@amd.com> Link: https://lore.kernel.org/r/20250311000416.817631-1-namhyung@kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-24perf trace: Fix wrong size to bpf_map__update_elem callThomas Richter
In linux-next commit c760174401f6 ("perf cpumap: Reduce cpu size from int to int16_t") causes the perf tests 100 126 to fail on s390: Output before: # ./perf test 100 100: perf trace BTF general tests : FAILED! # The root cause is the change from int to int16_t for the cpu maps. The size of the CPU key value pair changes from four bytes to two bytes. However a two byte key size is not supported for bpf_map__update_elem(). Note: validate_map_op() in libbpf.c emits warning libbpf: map '__augmented_syscalls__': \ unexpected key size 2 provided, expected 4 when key size is set to int16_t. Therefore change to variable size back to 4 bytes for invocation of bpf_map__update_elem(). Output after: # ./perf test 100 100: perf trace BTF general tests : Ok # Fixes: c760174401f6 ("perf cpumap: Reduce cpu size from int to int16_t") Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Ian Rogers <irogers@google.com> Acked-by: Howard Chu <howardchu95@gmail.com> Cc: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250324152756.3879571-1-tmricht@linux.ibm.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-24perf tools: annotate asm_pure_loop.SMarcus Meissner
Annotate so it is built with non-executable stack. Fixes: 8b97519711c3 ("perf test: Add asm pureloop test tool") Signed-off-by: Marcus Meissner <meissner@suse.de> Reviewed-by: Leo Yan <leo.yan@arm.com> Link: https://lore.kernel.org/r/20250323085410.23751-1-meissner@suse.de Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-24perf python: Fix setup.py mypy errorsIan Rogers
getenv may return None, so assert it isn't None for CC and srctree environmental variables required for the script. Disable an optional warning related to Popen. Reviewed-by: James Clark <james.clark@linaro.org> Signed-off-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250311213628.569562-7-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-24perf test: Address attr.py mypy errorIan Rogers
ConfigParser existed in python2 but not in python3 causing mypy to fail. Whilst removing a python2 workaround remove reference to __future__. Reviewed-by: James Clark <james.clark@linaro.org> Signed-off-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250311213628.569562-6-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-24perf build: Add pylint build testsIan Rogers
If PYLINT=1 is passed to the build then run pylint over python code in perf. Unlike shellcheck this isn't default on as there are currently too many errors. An example of an error: ``` ************* Module setup util/setup.py:19:0: C0301: Line too long (127/100) (line-too-long) util/setup.py:20:0: C0301: Line too long (138/100) (line-too-long) util/setup.py:63:0: C0301: Line too long (106/100) (line-too-long) util/setup.py:1:0: C0114: Missing module docstring (missing-module-docstring) util/setup.py:24:4: W0622: Redefining built-in 'vars' (redefined-builtin) util/setup.py:11:4: C0103: Constant name "cc_options" doesn't conform to UPPER_CASE naming style (invalid-name) util/setup.py:13:4: C0103: Constant name "cc_options" doesn't conform to UPPER_CASE naming style (invalid-name) util/setup.py:15:34: R1732: Consider using 'with' for resource-allocating operations (consider-using-with) util/setup.py:18:0: C0116: Missing function or method docstring (missing-function-docstring) util/setup.py:19:16: R1732: Consider using 'with' for resource-allocating operations (consider-using-with) util/setup.py:44:0: C0413: Import "from setuptools import setup, Extension" should be placed at the top of the module (wrong-import-position) util/setup.py:46:0: C0413: Import "from setuptools.command.build_ext import build_ext as _build_ext" should be placed at the top of the module (wrong-import-position) util/setup.py:47:0: C0413: Import "from setuptools.command.install_lib import install_lib as _install_lib" should be placed at the top of the module (wrong-import-position) util/setup.py:49:0: C0115: Missing class docstring (missing-class-docstring) util/setup.py:49:0: C0103: Class name "build_ext" doesn't conform to PascalCase naming style (invalid-name) util/setup.py:52:8: W0201: Attribute 'build_lib' defined outside __init__ (attribute-defined-outside-init) util/setup.py:53:8: W0201: Attribute 'build_temp' defined outside __init__ (attribute-defined-outside-init) util/setup.py:55:0: C0115: Missing class docstring (missing-class-docstring) util/setup.py:55:0: C0103: Class name "install_lib" doesn't conform to PascalCase naming style (invalid-name) util/setup.py:58:8: W0201: Attribute 'build_dir' defined outside __init__ (attribute-defined-outside-init) *----------------------------------------------------------------- Your code has been rated at 6.67/10 (previous run: 6.51/10, +0.16) make[4]: *** [util/Build:442: util/setup.py.pylint_log] Error 1 ``` Reviewed-by: James Clark <james.clark@linaro.org> Signed-off-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250311213628.569562-5-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-24perf build: Add mypy build testsIan Rogers
If MYPY=1 is passed to the build then run mypy over python code in perf. Unlike shellcheck this isn't default on as there are currently too many errors. An example of an error: ``` util/setup.py:8: error: Item "None" of "str | None" has no attribute "split" [union-attr] util/setup.py:15: error: Item "None" of "IO[bytes] | None" has no attribute "readline" [union-attr] util/setup.py:15: error: List item 0 has incompatible type "str | None"; expected "str | bytes | PathLike[str] | PathLike[bytes]" [list-item] util/setup.py:16: error: Unsupported left operand type for + ("None") [operator] util/setup.py:16: note: Left operand is of type "str | None" util/setup.py:74: error: Unsupported left operand type for + ("None") [operator] util/setup.py:74: note: Left operand is of type "str | None" Found 5 errors in 1 file (checked 1 source file) make[4]: *** [util/Build:430: util/setup.py.mypy_log] Error 1 ``` Reviewed-by: James Clark <james.clark@linaro.org> Signed-off-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250311213628.569562-4-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-24perf build: Rename TEST_LOGS to SHELL_TEST_LOGSIan Rogers
Rename TEST_LOGS to SHELL_TEST_LOGS as later changes will add more kinds of test logs. Minor comment tweak in Makefile.perf as more than just test shell tests are checked. Reviewed-by: James Clark <james.clark@linaro.org> Signed-off-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250311213628.569562-3-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-23perf bench sched pipe: fix enforced blocking reads in worker_threadDirk Gouders
The function worker_thread() is programmed in a way that roughly doubles the number of expectable context switches, because it enforces blocking reads: Performance counter stats for 'perf bench sched pipe': 2,000,004 context-switches 11.859548321 seconds time elapsed 0.674871000 seconds user 8.076890000 seconds sys The result of this behavior is that the blocking reads by far dominate the performance analysis of 'perf bench sched pipe': Samples: 78K of event 'cycles:P', Event count (approx.): 27964965844 Overhead Command Shared Object Symbol 25.28% sched-pipe [kernel.kallsyms] [k] read_hpet 8.11% sched-pipe [kernel.kallsyms] [k] retbleed_untrain_ret 2.82% sched-pipe [kernel.kallsyms] [k] pipe_write From the code, it is unclear if that behavior is wanted but the log says that at least Ingo Molnar aims to mimic lmbench's lat_ctx, that doesn't handle the pipe ends that way (https://sourceforge.net/p/lmbench/code/HEAD/tree/trunk/lmbench2/src/lat_ctx.c) Fix worker_thread() by always first feeding the write ends of the pipes and then trying to read. This roughly halves the context switches and runtime of pure 'perf bench sched pipe': Performance counter stats for 'perf bench sched pipe': 1,005,770 context-switches 6.033448041 seconds time elapsed 0.423142000 seconds user 4.519829000 seconds sys And the blocking reads do no longer dominate the analysis at the above extreme: Samples: 40K of event 'cycles:P', Event count (approx.): 14309364879 Overhead Command Shared Object Symbol 12.20% sched-pipe [kernel.kallsyms] [k] read_hpet 9.23% sched-pipe [kernel.kallsyms] [k] retbleed_untrain_ret 3.68% sched-pipe [kernel.kallsyms] [k] pipe_write Signed-off-by: Dirk Gouders <dirk@gouders.net> Acked-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20250323140316.19027-2-dirk@gouders.net Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-23perf tools: Fix is_compat_mode build break in ppc64Likhitha Korrapati
Commit 54f9aa1092457 ("tools/perf/powerpc/util: Add support to handle compatible mode PVR for perf json events") introduced to select proper JSON events in case of compat mode using auxiliary vector. But this caused a compilation error in ppc64 Big Endian. arch/powerpc/util/header.c: In function 'is_compat_mode': arch/powerpc/util/header.c:20:21: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 20 | if (!strcmp((char *)platform, (char *)base_platform)) | ^ arch/powerpc/util/header.c:20:39: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 20 | if (!strcmp((char *)platform, (char *)base_platform)) | Commit saved the getauxval(AT_BASE_PLATFORM) and getauxval(AT_PLATFORM) return values in u64 which causes the compilation error. Patch fixes this issue by changing u64 to "unsigned long". Fixes: 54f9aa1092457 ("tools/perf/powerpc/util: Add support to handle compatible mode PVR for perf json events") Signed-off-by: Likhitha Korrapati <likhitha@linux.ibm.com> Reviewed-by: Athira Rajeev <atrajeev@linux.ibm.com> Link: https://lore.kernel.org/r/20250321100726.699956-1-likhitha@linux.ibm.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-23perf build: filter all combinations of -flto for libperlHolger Hoffstätte
When enabling the libperl feature the build uses perl's build flags (ccopts) but filters out various flags, e.g. for LTO. While this is conceptually correct, it is insufficient in practice, since only "-flto=auto" is filtered out. When perl itself is built with "-flto" this can cause parts of perf being built with LTO and others without, giving exciting build errors like e.g.: ../tools/perf/pmu-events/pmu-events.c:72851:(.text+0xb79): undefined reference to `strcmp_cpuid_str' collect2: error: ld returned 1 exit status Fix this by filtering all matching flag values of -flto{=n,auto,..}. Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com> Link: https://lore.kernel.org/r/20250321082038.27901-2-holger@applied-asynchrony.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf vendor events arm64 AmpereOneX: Fix frontend_bound calculationIlkka Koskinen
frontend_bound metrics was miscalculated due to different scaling in a couple of metrics it depends on. Change the scaling to match with AmpereOne. Fixes: 16438b652b46 ("perf vendor events arm64 AmpereOneX: Add core PMU events and metrics") Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Reviewed-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250313201559.11332-3-ilkka@os.amperecomputing.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf vendor events arm64: AmpereOne/AmpereOneX: Mark LD_RETIRED impacted by ↵Ilkka Koskinen
errata Atomic instructions are both memory-reading and memory-writing instructions and so should be counted by both LD_RETIRED and ST_RETIRED performance monitoring events. However LD_RETIRED does not count atomic instructions. Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Reviewed-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250313201559.11332-2-ilkka@os.amperecomputing.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf trace: Fix evlist memory leakIan Rogers
Leak sanitizer was reporting a memory leak in the "perf record and replay" test. Add evlist__delete to trace__exit, also ensure trace__exit is called after trace__record. Signed-off-by: Ian Rogers <irogers@google.com> Reviewed-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Link: https://lore.kernel.org/r/20250319050741.269828-15-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf trace: Fix BTF memory leakIan Rogers
Add missing btf__free in trace__exit. Signed-off-by: Ian Rogers <irogers@google.com> Reviewed-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Link: https://lore.kernel.org/r/20250319050741.269828-14-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf trace: Make syscall table stableIan Rogers
Namhyung fixed the syscall table being reallocated and moving by reloading the system call pointer after a move: https://lore.kernel.org/lkml/Z9YHCzINiu4uBQ8B@google.com/ This could be brittle so this patch changes the syscall table to be an array of pointers of "struct syscall" that don't move. Remove unnecessary copies and searches with this change. Signed-off-by: Ian Rogers <irogers@google.com> Reviewed-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Link: https://lore.kernel.org/r/20250319050741.269828-13-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf syscalltbl: Mask off ABI type for MIPS system callsIan Rogers
Arnd Bergmann described that MIPS system calls don't necessarily start from 0 as an ABI prefix is applied: https://lore.kernel.org/lkml/8ed7dfb2-1e4d-4aa4-a04b-0397a89365d1@app.fastmail.com/ When decoding the "id" (aka system call number) for MIPS ignore values greater-than 1000. Signed-off-by: Ian Rogers <irogers@google.com> Reviewed-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Link: https://lore.kernel.org/r/20250319050741.269828-12-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf build: Remove Makefile.syscallsIan Rogers
Now a single beauty file is generated and used by all architectures, remove the per-architecture Makefiles, Kbuild files and previous generator script. Note: there was conversation with Charlie Jenkins <charlie@rivosinc.com> and they'd written an alternate approach to support multiple architectures: https://lore.kernel.org/all/20250114-perf_syscall_arch_runtime-v1-1-5b304e408e11@rivosinc.com/ It would have been better to have helped Charlie fix their series (my apologies) but they agreed that the approach taken here was likely best for longer term maintainability: https://lore.kernel.org/lkml/Z6Jk_UN9i69QGqUj@ghost/ Signed-off-by: Ian Rogers <irogers@google.com> Reviewed-by: Howard Chu <howardchu95@gmail.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Link: https://lore.kernel.org/r/20250319050741.269828-11-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf syscalltbl: Use lookup table containing multiple architecturesIan Rogers
Switch to use the lookup table containing all architectures rather than tables matching the perf binary. This fixes perf trace when executed on a 32-bit i386 binary on an x86-64 machine. Note in the following the system call names of the 32-bit i386 binary as seen by an x86-64 perf. Before: ``` ? ( ): a.out/447296 ... [continued]: munmap()) = 0 0.024 ( 0.001 ms): a.out/447296 recvfrom(ubuf: 0x2, size: 4160585708, flags: DONTROUTE|CTRUNC|TRUNC|DONTWAIT|EOR|WAITALL|FIN|SYN|CONFIRM|RST|ERRQUEUE|NOSIGNAL|WAITFORONE|BATCH|SOCK_DEVMEM|ZEROCOPY|FASTOPEN|CMSG_CLOEXEC|0x91f80000, addr: 0xe30, addr_len: 0xffce438c) = 1475198976 0.042 ( 0.003 ms): a.out/447296 lgetxattr(name: "", value: 0x3, size: 34) = 4160344064 0.054 ( 0.003 ms): a.out/447296 dup2(oldfd: -134422744, newfd: 4) = -1 ENOENT (No such file or directory) 0.060 ( 0.009 ms): a.out/447296 preadv(fd: 4294967196, vec: (struct iovec){.iov_base = (void *)0x2e646c2f6374652f,.iov_len = (__kernel_size_t)7307199665335594867,}, vlen: 557056, pos_h: 4160585708) = 3 0.074 ( 0.004 ms): a.out/447296 lgetxattr(name: "", value: 0x1, size: 2) = 4160237568 0.080 ( 0.001 ms): a.out/447296 lstat(filename: "", statbuf: 0x193f6) = 0 0.089 ( 0.007 ms): a.out/447296 preadv(fd: 4294967196, vec: (struct iovec){.iov_base = (void *)0x3833692f62696c2f,.iov_len = (__kernel_size_t)3276497845987585334,}, vlen: 557056, pos_h: 4160585708) = 3 0.097 ( 0.002 ms): a.out/447296 close(fd: 3</proc/447296/status>) = 512 0.103 ( 0.002 ms): a.out/447296 lgetxattr(name: "", value: 0x1, size: 2050) = 4157935616 0.107 ( 0.007 ms): a.out/447296 lgetxattr(pathname: "", name: "", value: 0x5, size: 2066) = 4158078976 0.116 ( 0.003 ms): a.out/447296 lgetxattr(pathname: "", name: "", value: 0x1, size: 2066) = 4159639552 0.121 ( 0.003 ms): a.out/447296 lgetxattr(pathname: "", name: "", value: 0x3, size: 2066) = 4160184320 0.129 ( 0.002 ms): a.out/447296 lgetxattr(pathname: "", name: "", value: 0x3, size: 50) = 4160196608 0.138 ( 0.001 ms): a.out/447296 lstat(filename: "") = 0 0.145 ( 0.002 ms): a.out/447296 mq_timedreceive(mqdes: 4291706800, u_msg_ptr: 0xf7f9ea48, msg_len: 134616640, u_msg_prio: 0xf7fd7fec, u_abs_timeout: (struct __kernel_timespec){.tv_sec = (__kernel_time64_t)-578174027777317696,.tv_nsec = (long long int)4160349376,}) = 0 0.148 ( 0.001 ms): a.out/447296 mkdirat(dfd: -134617816, pathname: " ��� ���▒���▒���", mode: IFREG|ISUID|IRUSR|IWGRP|0xf7fd0000) = 447296 0.150 ( 0.001 ms): a.out/447296 process_vm_writev(pid: -134617812, lvec: (struct iovec){.iov_base = (void *)0xf7f9e9c8f7f9e4c0,.iov_len = (__kernel_size_t)4160349376,}, liovcnt: 4160588048, rvec: (struct iovec){}, riovcnt: 4160585708, flags: 4291707352) = 0 0.197 ( 0.004 ms): a.out/447296 capget(header: 4160184320, dataptr: 8192) = 0 0.202 ( 0.002 ms): a.out/447296 capget(header: 1448669184, dataptr: 4096) = 0 0.208 ( 0.002 ms): a.out/447296 capget(header: 4160577536, dataptr: 8192) = 0 0.220 ( 0.001 ms): a.out/447296 getxattr(pathname: "", name: "c������", value: 0xf7f77e34, size: 1) = 0 0.228 ( 0.005 ms): a.out/447296 fchmod(fd: -134729728, mode: IRUGO|IWUGO|IFREG|IFIFO|ISVTX|IXUSR|0x10000) = 0 0.240 ( 0.009 ms): a.out/447296 preadv(fd: 4294967196, vec: 0x5658e008, pos_h: 4160192052) = 3 0.250 ( 0.008 ms): a.out/447296 close(fd: 3</proc/447296/status>) = 1436 0.260 ( 0.018 ms): a.out/447296 stat(filename: "", statbuf: 0xffce32ac) = 1436 0.288 (1000.213 ms): a.out/447296 readlinkat(buf: 0xffce31d4, bufsiz: 4291703244) = 0 ``` After: ``` ? ( ): a.out/442930 ... [continued]: execve()) = 0 0.023 ( 0.002 ms): a.out/442930 brk() = 0x57760000 0.052 ( 0.003 ms): a.out/442930 access(filename: 0xf7f5af28, mode: R) = -1 ENOENT (No such file or directory) 0.059 ( 0.009 ms): a.out/442930 openat(dfd: CWD, filename: "/etc/ld.so.cache", flags: RDONLY|CLOEXEC|LARGEFILE) = 3 0.078 ( 0.001 ms): a.out/442930 close(fd: 3</proc/442930/status>) = 0 0.087 ( 0.007 ms): a.out/442930 openat(dfd: CWD, filename: "/lib/i386-linux-", flags: RDONLY|CLOEXEC|LARGEFILE) = 3 0.095 ( 0.002 ms): a.out/442930 read(fd: 3</proc/442930/status>, buf: 0xffbdbb70, count: 512) = 512 0.135 ( 0.001 ms): a.out/442930 close(fd: 3</proc/442930/status>) = 0 0.148 ( 0.001 ms): a.out/442930 set_tid_address(tidptr: 0xf7f2b528) = 442930 (a.out) 0.150 ( 0.001 ms): a.out/442930 set_robust_list(head: 0xf7f2b52c, len: 12) = 0.196 ( 0.004 ms): a.out/442930 mprotect(start: 0xf7f03000, len: 8192, prot: READ) = 0 0.202 ( 0.002 ms): a.out/442930 mprotect(start: 0x5658e000, len: 4096, prot: READ) = 0 0.207 ( 0.002 ms): a.out/442930 mprotect(start: 0xf7f63000, len: 8192, prot: READ) = 0 0.230 ( 0.005 ms): a.out/442930 munmap(addr: 0xf7f10000, len: 103414) = 0 0.244 ( 0.010 ms): a.out/442930 openat(dfd: CWD, filename: 0x5658d008) = 3 0.255 ( 0.007 ms): a.out/442930 read(fd: 3</proc/442930/status>, buf: 0xffbdb67c, count: 4096) = 1436 0.264 ( 0.018 ms): a.out/442930 write(fd: 1</dev/pts/4>, buf: , count: 1436) = 1436 0.292 (1000.173 ms): a.out/442930 clock_nanosleep(rqtp: { .tv_sec: 17866546940376776704, .tv_nsec: 4159878336 }, rmtp: 0xffbdb59c) = 0 1000.478 ( ): a.out/442930 exit_group() = ? ``` Signed-off-by: Ian Rogers <irogers@google.com> Reviewed-by: Howard Chu <howardchu95@gmail.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Link: https://lore.kernel.org/r/20250319050741.269828-10-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf trace beauty: Add syscalltbl.sh generating all system call tablesIan Rogers
Rather than generating individual syscall header files generate a single trace/beauty/generated/syscalltbl.c. In a syscalltbls array have references to each architectures tables along with the corresponding e_machine. When the 32-bit or 64-bit table is ambiguous, match the perf binary's type. For ARM32 don't use the arm64 32-bit table which is smaller. EM_NONE is present for is no machine matches. Conditionally compile the tables, only having the appropriate 32 and 64-bit table. If ALL_SYSCALLTBL is defined all tables can be compiled. Add comment for noreturn column suggested by Arnd Bergmann: https://lore.kernel.org/lkml/d47c35dd-9c52-48e7-a00d-135572f11fbb@app.fastmail.com/ and added in commit 9142be9e6443 ("x86/syscall: Mark exit[_group] syscall handlers __noreturn"). Signed-off-by: Ian Rogers <irogers@google.com> Reviewed-by: Howard Chu <howardchu95@gmail.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Link: https://lore.kernel.org/r/20250319050741.269828-9-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf thread: Add support for reading the e_machine type for a threadIan Rogers
First try to read the e_machine from the dsos associated with the thread's maps. If live use the executable from /proc/pid/exe and read the e_machine from the ELF header. On failure use EM_HOST. Change builtin-trace syscall functions to pass e_machine from the thread rather than EM_HOST, so that in later patches when syscalltbl can use the e_machine the system calls are specific to the architecture. Signed-off-by: Ian Rogers <irogers@google.com> Reviewed-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Link: https://lore.kernel.org/r/20250319050741.269828-8-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf dso: Add support for reading the e_machine type for a dsoIan Rogers
For ELF file dsos read the e_machine from the ELF header. For kernel types assume the e_machine matches the perf tool. In other cases return EM_NONE. When reading from the ELF header use DSO__SWAP that may need dso->needs_swap initializing. Factor out dso__swap_init to allow this. Signed-off-by: Ian Rogers <irogers@google.com> Reviewed-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Link: https://lore.kernel.org/r/20250319050741.269828-7-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf syscalltbl: Remove struct syscalltblIan Rogers
The syscalltbl held entries of system call name and number pairs, generated from a native syscalltbl at start up. As there are gaps in the system call number there is a notion of index into the table. Going forward we want the system call table to be identifiable by a machine type, for example, i386 vs x86-64. Change the interface to the syscalltbl so (1) a (currently unused machine type of EM_HOST) is passed (2) the index to syscall number and system call name mapping is computed at build time. Two tables are used for this, an array of system call number to name, an array of system call numbers sorted by the system call name. The sorted array doesn't store strings in part to save memory and relocations. The index notion is carried forward and is an index into the sorted array of system call numbers, the data structures are opaque (held only in syscalltbl.c), and so the number of indices for a machine type is exposed as a new API. The arrays are computed in the syscalltbl.sh script and so no start-up time computation and storage is necessary. Signed-off-by: Ian Rogers <irogers@google.com> Reviewed-by: Howard Chu <howardchu95@gmail.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Link: https://lore.kernel.org/r/20250319050741.269828-6-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf trace: Reorganize syscallsIan Rogers
Identify struct syscall information in the syscalls table by a machine type and syscall number, not just system call number. Having the machine type means that 32-bit system calls can be differentiated from 64-bit ones on a machine capable of both. Having a table for all machine types and all system call numbers would be too large, so maintain a sorted array of system calls as they are encountered. Signed-off-by: Ian Rogers <irogers@google.com> Reviewed-by: Howard Chu <howardchu95@gmail.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Link: https://lore.kernel.org/r/20250319050741.269828-5-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf syscalltbl: Remove syscall_table.hIan Rogers
The definition of "static const char *const syscalltbl[] = {" is done in a generated syscalls_32.h or syscalls_64.h that is architecture dependent. In order to include the appropriate file a syscall_table.h is found via the perf include path and it includes the syscalls_32.h or syscalls_64.h as appropriate. To support having multiple syscall tables, one for 32-bit and one for 64-bit, or for different architectures, an include path cannot be used. Remove syscall_table.h because of this and inline what it does into syscalltbl.c. For architectures without a syscall_table.h this will cause a failure to include either syscalls_32.h or syscalls_64.h rather than a failure to include syscall_table.h. For architectures that only included one or other, the behavior matches BITS_PER_LONG as previously done on architectures supporting both syscalls_32.h and syscalls_64.h. Signed-off-by: Ian Rogers <irogers@google.com> Reviewed-by: Howard Chu <howardchu95@gmail.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Link: https://lore.kernel.org/r/20250319050741.269828-4-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf dso: kernel-doc for enum dso_binary_typeIan Rogers
There are many and non-obvious meanings to the dso_binary_type enum values. Add kernel-doc to speed interpretting their meanings. Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ian Rogers <irogers@google.com> Reviewed-by: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/20250319050741.269828-3-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf dso: Move libunwind dso_data variables into ifdefIan Rogers
The variables elf_base_addr, debug_frame_offset, eh_frame_hdr_addr and eh_frame_hdr_offset are only accessed in unwind-libunwind-local.c which is conditionally built on having libunwind support. Make the variables conditional on libunwind support too. Reviewed-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ian Rogers <irogers@google.com> Reviewed-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Arnaldo Carvalho de Melo <acme@kernel.org> Link: https://lore.kernel.org/r/20250319050741.269828-2-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf report: Disable children column for data type profilingNamhyung Kim
I've realized that it doesn't make sense to accumulate the samples to parent in the callchain when data type profiling is enabled. Because it won't have the same data type access in the parent. Otherwise it'd see something like this: $ perf report -s type --stdio -g none # To display the perf.data header info, please use --header/--header-only options. # # # Total Lost Samples: 0 # # Samples: 2K of event 'cycles:Pu' # Event count (approx.): 8266456478 # # Children Latency Self Latency Data Type # ........ ....... ........ ........ ......... # 698.97% 697.72% 99.80% 99.61% (unknown) 0.09% 0.18% 0.09% 0.18% Elf64_Rela 0.05% 0.10% 0.05% 0.10% unsigned char 0.05% 0.10% 0.05% 0.10% struct exit_function_list 0.00% 0.01% 0.00% 0.01% struct rtld_global Link: https://lore.kernel.org/r/20250307080829.354947-3-namhyung@kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf report: Allow hierarchy mode for --childrenNamhyung Kim
It was prohibited because the output fields in the children mode were not handled properly with hierarchy. But we can have the output fields in the same level, it can allow them together. For example, latency mode adds more output fields by default and now they are displayed properly. $ perf record --latency -g -- perf test -w thloop $ perf report -H --stdio # To display the perf.data header info, please use --header/--header-only options. # # # Total Lost Samples: 0 # # Samples: 2K of event 'cycles:Pu' # Event count (approx.): 8266456478 # # Children Latency Overhead Latency Command / Shared Object / Symbol # ........................................... ........................................................ # 0.08% 0.16% 100.00% 100.00% perf 0.08% 0.16% 0.24% 0.47% ld-linux-x86-64.so.2 0.12% 0.24% 0.12% 0.24% [.] _dl_relocate_object 0.08% 0.16% 0.08% 0.16% [.] _dl_lookup_symbol_x 0.03% 0.06% 0.03% 0.06% [.] strcmp 0.00% 0.01% 0.00% 0.01% [.] _dl_start 0.00% 0.00% 0.00% 0.00% [.] _dl_start_user 0.00% 0.00% 0.00% 0.00% [.] _dl_sysdep_start 0.00% 0.00% 0.00% 0.00% [.] _start 0.00% 0.00% 0.00% 0.00% [.] dl_main 0.03% 0.06% 0.03% 0.06% libLLVM-16.so.1 0.03% 0.06% 0.03% 0.06% [.] llvm::StringMapImpl::RehashTable(unsigned int) 0.00% 0.00% 0.00% 0.00% [.] 0x00007f137ccd18e8 0.00% 0.00% 99.66% 99.31% perf 99.66% 99.31% 99.66% 99.31% [.] test_loop | |--49.86%--0x7f137b633d68 | 0x55dbdbbb7d2c ... Link: https://lore.kernel.org/r/20250307080829.354947-2-namhyung@kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-20perf sort: Keep output fields in the same levelNamhyung Kim
This is useful for hierarchy output mode where the first level is considered as output fields. We want them in the same level so that it can show only the remaining groups in the hierarchy. Before: $ perf report -s overhead,sample,period,comm,dso -H --stdio ... # Overhead Samples / Period / Command / Shared Object # ................. .......................................... # 100.00% 4035 100.00% 3835883066 100.00% perf 99.37% perf 0.50% ld-linux-x86-64.so.2 0.06% [unknown] 0.04% libc.so.6 0.02% libLLVM-16.so.1 After: $ perf report -s overhead,sample,period,comm,dso -H --stdio ... # Overhead Samples Period Command / Shared Object # ....................................... ....................... # 100.00% 4035 3835883066 perf 99.37% 4005 3811826223 perf 0.50% 19 19210014 ld-linux-x86-64.so.2 0.06% 8 2367089 [unknown] 0.04% 2 1720336 libc.so.6 0.02% 1 759404 libLLVM-16.so.1 Acked-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20250307080829.354947-1-namhyung@kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2025-03-19perf pmu: Handle memory failure in tool_pmu__new()Thomas Richter
On linux-next commit 72c6f57a4193 ("perf pmu: Dynamically allocate tool PMU") allocated PMU named "tool" dynamicly. However that allocation can fail and a NULL pointer is returned. That case is currently not handled and would result in an invalid address reference. Add a check for NULL pointer. Fixes: 72c6f57a4193 ("perf pmu: Dynamically allocate tool PMU") Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250319122820.2898333-1-tmricht@linux.ibm.com Signed-off-by: Namhyung Kim <namhyung@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 10:16:20 +0000