kernel/tools/perf/util/machine.c, branch linux-6.16.y

perf callchain: Always populate the addr_location map when adding IP

2025-05-31T11:58:30Z

Dropping symbols also meant the callchain maps wasn't populated, but the callchain map is needed to find the DSO. Plumb the symbols option better, falling back to thread__find_map() rather than thread__find_symbol() when symbols are disabled. Fixes: 02b2705017d2e5ad ("perf callchain: Allow symbols to be optional when resolving a callchain") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Athira Rajeev Cc: Ben Gainey Cc: Chaitanya S Prakash Cc: Charlie Jenkins Cc: Chun-Tse Shao Cc: Colin Ian King Cc: Dmitriy Vyukov Cc: Dr. David Alan Gilbert Cc: Graham Woodward Cc: Howard Chu Cc: Ilkka Koskinen Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: John Garry Cc: Kajol Jain Cc: Kan Liang Cc: Krzysztof Łopatowski Cc: Leo Yan Cc: Levi Yun Cc: Li Huafei Cc: linux-arm-kernel@lists.infradead.org Cc: Mark Rutland Cc: Martin Liška Cc: Masami Hiramatsu Cc: Matt Fleming Cc: Mike Leach Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Song Liu Cc: Steinar H. Gunderson Cc: Stephen Brennan Cc: Steve Clevenger Cc: Thomas Falcon Cc: Veronika Molnarova Cc: Weilin Wang Cc: Will Deacon Cc: Yicong Yang Cc: Yujie Liu Cc: Zhongqiu Han Cc: Zixian Cai Link: https://lore.kernel.org/r/20250529044000.759937-2-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo

perf machine: Factor creating a "live" machine out of dwarf-unwind

2025-05-28T12:24:59Z

Factor out for use in places other than the dwarf unwinding tests for libunwind. Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Anne Macedo Cc: Dmitriy Vyukov Cc: Dr. David Alan Gilbert Cc: Howard Chu Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Yicong Yang Link: https://lore.kernel.org/r/20250313052952.871958-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo

perf report: Do not process non-JIT BPF ksymbol events

2025-03-07T00:00:25Z

The length of PERF_RECORD_KSYMBOL for BPF is a size of JITed code so it'd be 0 when it's not JITed. The ksymbol is needed to symbolize the code when it gets samples in the region but non-JITed code cannot get samples. Thus it'd be ok to ignore them. Actually it caused a performance issue in the perf tools on old ARM kernels where it can refuse to JIT some BPF codes. It ended up splitting the existing kernel map (kallsyms). And later lookup for a kernel symbol would create a new kernel map from kallsyms and then split it again and again. :( Probably there's a bug in the kernel map/symbol handling in perf tools. But I think we need to fix this anyway. Reported-by: Kevin Nomura Acked-by: Song Liu Link: https://lore.kernel.org/r/20250305232838.128692-1-namhyung@kernel.org Signed-off-by: Namhyung Kim

perf machine: Fix insertion of PERF_RECORD_KSYMBOL related kernel maps

2025-03-06T07:04:07Z

This was detected at the end of a 'perf record' session when build-id collection was enabled and thus the BPF programs put in place while the session was running, some even put in place by perf itself were processed and inserted, with some overlaps related to BPF trampolines and programs took place. Using maps__fixup_overlap_and_insert() instead of maps__insert() "fixes" the problem, in the sense that overlaps will be dealt with and then the consistency will be kept, but it would be interesting to fully understand why such overlaps take place and how to deal with them when doing symbol resolution. Reported-by: Arnaldo Carvalho de Melo Suggested-by: Ian Rogers Tested-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/lkml/CAP-5=fXEEMFgPF2aZhKsfrY_En+qoqX20dWfuE_ad73Uxf0ZHQ@mail.gmail.com Link: https://lore.kernel.org/r/20250228211734.33781-7-acme@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim

perf machine: Fixup kernel maps ends after adding extra maps

2025-03-06T07:03:15Z

I just noticed it would add extra kernel maps after modules. I think it should fixup end address of the kernel maps after adding all maps first. Fixes: 876e80cf83d10585 ("perf tools: Fixup end address of modules") Reported-by: Arnaldo Carvalho de Melo Tested-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/lkml/Z7TvZGjVix2asYWI@x1 Link: https://lore.kernel.org/lkml/Z712hzvv22Ni63f1@google.com Link: https://lore.kernel.org/r/20250228211734.33781-4-acme@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim

perf machine: Reuse module path buffer

2025-02-24T23:46:33Z

Rather than copying the path and appending the directory entry in a fresh path buffer, append to the path at the end of where it is for the recursion level. This saves a PATH_MAX buffer per recursion level and some unnecessary copying. Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250222061015.303622-9-irogers@google.com Signed-off-by: Namhyung Kim

perf maps: Switch modules tree walk to io_dir__readdir

2025-02-24T23:46:33Z

Compared to glibc's opendir/readdir this lowers the max RSS of perf record by 1.8MB on a Debian machine. Acked-by: Namhyung Kim Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250222061015.303622-3-irogers@google.com Signed-off-by: Namhyung Kim

perf tools: Improve startup time by reducing unnecessary stat() calls

2025-02-19T21:55:59Z

When testing perf trace on NixOS, I noticed significant startup delays: - `ls`: ~2ms - `strace ls`: ~10ms - `perf trace ls`: ~550ms Profiling showed that 51% of the time is spent reading files, 26% in loading BPF programs, and 11% in `newfstatat`. This patch optimizes module path exploration by avoiding `stat()` calls unless necessary. For filesystems that do not implement `d_type` (DT_UNKNOWN), it falls back to the old behavior. See `readdir(3)` for details. This reduces `perf trace ls` time to ~500ms. A more thorough startup optimization based on command parameters would be ideal, but that is a larger effort. Signed-off-by: Krzysztof Łopatowski Acked-by: Howard Chu Link: https://lore.kernel.org/r/20250206113314.335376-2-krzysztof.m.lopatowski@gmail.com Signed-off-by: Namhyung Kim

perf report: Add machine parallelism

2025-02-18T06:00:50Z

Add calculation of the current parallelism level (number of threads actively running on CPUs). The parallelism level can be shown in reports on its own, and to calculate latency overheads. Signed-off-by: Dmitry Vyukov Reviewed-by: Andi Kleen Link: https://lore.kernel.org/r/0f8c1b8eb12619029e31b3d5c0346f4616a5aeda.1739437531.git.dvyukov@google.com Signed-off-by: Namhyung Kim

perf sample: Make user_regs and intr_regs optional

2025-02-13T04:06:11Z

The struct dump_regs contains 512 bytes of cache_regs, meaning the two values in perf_sample contribute 1088 bytes of its total 1384 bytes size. Initializing this much memory has a cost reported by Tavian Barnes as about 2.5% when running `perf script --itrace=i0`: https://lore.kernel.org/lkml/d841b97b3ad2ca8bcab07e4293375fb7c32dfce7.1736618095.git.tavianator@tavianator.com/ Adrian Hunter replied that the zero initialization was necessary and couldn't simply be removed. This patch aims to strike a middle ground of still zeroing the perf_sample, but removing 79% of its size by make user_regs and intr_regs optional pointers to zalloc-ed memory. To support the allocation accessors are created for user_regs and intr_regs. To support correct cleanup perf_sample__init and perf_sample__exit functions are created and added throughout the code base. Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250113194345.1537821-1-irogers@google.com Signed-off-by: Namhyung Kim