linux-toradex.git/tools/perf/util/bpf_skel, branch master

perf lock contention: Enable end-timestamp accounting for cgroup aggregation

2026-06-04T20:34:52+00:00

update_lock_stat() handles lock contentions that start but never reach a
contention_end event (e.g., locks still held when profiling stops), but
previously treated LOCK_AGGR_CGROUP as a no-op due to missing cgroup
context in userspace.

Fix this by adding a cgroup_id field to struct tstamp_data, recording it
at contention_begin using get_current_cgroup_id() when aggr_mode is
LOCK_AGGR_CGROUP. Capturing it at contention_begin is semantically
correct, the contention cost is incurred by the task that had to wait,
not by whatever task happens to be running at contention_end. It is also
preferable from a performance standpoint, as contention_end runs just
before the task enters the critical section.

Update contention_end to use pelem->cgroup_id instead of calling
get_current_cgroup_id() dynamically, ensuring both complete and
incomplete contention events attribute the wait time to the cgroup at
wait-start time consistently.

Reviewed-by: Namhyung Kim 
Signed-off-by: Suchit Karunakaran 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Ian Rogers 
Cc: Ingo Molnar 
Cc: James Clark 
Cc: Jiri Olsa 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Tycho Andersen (AMD) 
Signed-off-by: Arnaldo Carvalho de Melo

perf lock contention: Allow 'mmap_lock' in -L/--lock-filter

2026-06-04T20:34:52+00:00

The -L/--lock-filter option is to specify target locks by name or
address.  It's basically for global locks where name or address is known
and fixed.  But 'mmap_lock' is a per-process lock so it cannot be used
for the -L option.

  $ sudo perf lock con -ab -L mmap_lock
  ignore unknown symbol: mmap_lock
  libbpf: map 'addr_filter': failed to create: -EINVAL
  libbpf: failed to load BPF skeleton 'lock_contention_bpf': -EINVAL
  Failed to load lock-contention BPF skeleton
  lock contention BPF setup failed

However, it's still a common source of contention especially in a large
process so we want to use it for the -L/--lock-filter option.  As there
is check_lock_type() to check mmap_lock at runtime, let's used it to
filter mmap_locks as a special case.

Of course, this only works with -b/--use-bpf option.

  $ sudo perf lock con -b -L mmap_lock -- perf bench mem mmap -f demand -t 2
  # Running 'mem/mmap' benchmark:
  # function 'demand' (Demand loaded mmap())
  # Copying 1MB bytes ...

         2.679184 GB/sec/thread	( +-   1.78% )
   contended   total wait     max wait     avg wait         type   caller

           1     15.22 us     15.22 us     15.22 us      rwsem:W   __vm_munmap+0x7e
           1      7.72 us      7.72 us      7.72 us      rwsem:R   lock_mm_and_find_vma+0x97

Signed-off-by: Namhyung Kim 
Cc: Adrian Hunter 
Cc: Ian Rogers 
Cc: Ingo Molnar 
Cc: James Clark 
Cc: Jiri Olsa 
Cc: Peter Zijlstra 
Cc: Suchit Karunakaran 
Signed-off-by: Arnaldo Carvalho de Melo

perf lock: Fix non-atomic max/time and min_time updates in contention_data

2026-06-04T13:33:06+00:00

The update_contention_data() had a FIXME noting that max_time and
min_time updates lacked atomicity. Two CPUs could simultaneously read a
stale value, pass the comparison check and race on the write-back, with
the smaller value potentially overwriting the larger one and silently
corrupting the statistics.

Fix this by replacing the bare conditional assignments with a
bpf_loop()-based CAS retry loop. Each field tracks its own convergence
independently via max_done/min_done flags in cas_ctx, so a successful
CAS on one field is never retried even if the other field needs more
attempts.

Signed-off-by: Suchit Karunakaran 
Acked-by: Namhyung Kim 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Ian Rogers 
Cc: Ingo Molnar 
Cc: James Clark 
Cc: Jiri Olsa 
Cc: Mark Rutland 
Signed-off-by: Arnaldo Carvalho de Melo

perf build: Move BPF skeleton generation out of Makefile.perf

2026-05-20T20:46:45+00:00

Currently, the top-level Makefile.perf defines a massive global bpf-skel
umbrella target that pre-compiles all 12+ BPF skeletons (%.skel.h) upfront
before launching sub-makes. This forces unrelated sub-makes to serialize
behind bpftool and clang BPF target evaluations, causing parallel build
bottlenecks.

Furthermore, bench_uprobe.bpf.c lived inside util/bpf_skel/, breaking
conceptual directory encapsulation since it is consumed purely by
bench/uprobe.c.

Refactor the BPF skeletons to better achieve directory isolation:
1. Move tools/perf/util/bpf_skel/bench_uprobe.bpf.c directly into
   tools/perf/bench/bpf_skel/.
2. Extract the skeleton generation infrastructure out of Makefile.perf into
   a shared inclusion file tools/perf/bpf_skel.mak.
3. Include bpf_skel.mak locally inside tools/perf/util/Build and
   tools/perf/bench/Build and bind precise local prerequisites.
4. Safely synchronize the shared bpftool bootstrap and vmlinux.h targets
   via the conditional prepare: umbrella to avoid parallel sub-make races,
   while evaluating the actual skeletons completely locally on demand. A
   later patch will move these targets into bpf_skel.mak.
5. Export CLANG from the global Makefile to ensure accurate tool
   propagation.
6. Clean up Makefile.perf by stripping the global bpf-skel umbrella target
   and its SKELETONS list.

While removing code from Makefile.perf generally helps build
performance, the impact here is minimal. The main motivation for the
change is to better encapsulate things in the build and simplify
Makefile.perf that has around 50 lines removed.

Reviewed-by: Namhyung Kim 
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Ian Rogers 
Tested-by: James Clark 
Cc: Adrian Hunter 
Cc: Albert Ou 
Cc: Alexandre Chartre 
Cc: Alexandre Ghiti 
Cc: Andrii Nakryiko 
Cc: Ankur Arora 
Cc: Collin Funk 
Cc: Costa Shulyupin 
Cc: Daniel Borkmann 
Cc: Dapeng Mi 
Cc: David Sterba 
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: Eduard Zingerman 
Cc: Howard Chu 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Kumar Kartikeya Dwivedi 
Cc: Leo Yan 
Cc: Markus Mayer 
Cc: Martin KaFai Lau 
Cc: Nathan Chancellor 
Cc: Nick Terrell 
Cc: Palmer Dabbelt 
Cc: Paul Walmsley 
Cc: Peter Zijlstra 
Cc: Quentin Monnet 
Cc: Ricky Ringler 
Cc: Song Liu 
Cc: Swapnil Sapkal 
Cc: Thomas Falcon 
Cc: Tomas Glozar 
Cc: Yonghong Song 
Signed-off-by: Arnaldo Carvalho de Melo

perf trace: Handle task exit in BPF syscall summary

2026-02-26T18:49:00+00:00

Some system calls never return because it'd terminate the calling
thread.  Let's hook the task exit path and update the duration of the
last syscall.

Before:
  $ sudo perf trace -as --bpf-summary -- true |& grep exit
  (nothing)

After:
  $ sudo perf trace -as --bpf-summary -- true |& grep exit
     exit_group             1      0     0.004     0.004     0.004     0.004      0.00%

Reviewed-by: Ian Rogers 
Acked-by: Howard Chu 
Signed-off-by: Namhyung Kim

perf trace: Increase syscall handler map size to 1024

2025-10-31T19:29:44+00:00

The syscalls_sys_{enter,exit} map in augmented_raw_syscalls.bpf.c has
max entries of 512.  Usually syscall numbers are smaller than this but
x86 has x32 ABI where syscalls start from 512.

That makes trace__init_syscalls_bpf_prog_array_maps() fail in the middle
of the loop when it accesses those keys.  As the loop iteration is not
ordered by syscall numbers anymore, the failure can affect non-x32
syscalls.

Let's increase the map size to 1024 so that it can handle those ABIs
too.  While most systems won't need this, increasing the size will be
safer for potential future changes.

Reviewed-by: Howard Chu 
Signed-off-by: Namhyung Kim

perf stat: Add/fix bperf cgroup max events workarounds

2025-10-25T23:44:21+00:00

Commit b8308511f6e0 bumped the max events to 1024 but this results in
BPF verifier issues if the number of command line events is too
large. Workaround this by:

1) moving the constants to a header file to share between BPF and perf
   C code,
2) testing that the maximum number of events doesn't cause BPF
   verifier issues in debug builds,
3) lower the max events from 1024 to 128,
4) in perf stat, if there are more events than the BPF counters can
   support then disable BPF counter usage.

The rodata setup is factored into its own function to avoid
duplicating it in the testing code.

Signed-off-by: Ian Rogers 
Fixes: b8308511f6e0 ("perf stat bperf cgroup: Increase MAX_EVENTS from 32 to 1024")
Signed-off-by: Namhyung Kim

perf stat bperf cgroup: Increase MAX_EVENTS from 32 to 1024

2025-10-19T03:35:40+00:00

The MAX_EVENTS value ensured a counted loop presumably to satisfy the
BPF verifier. It is possible to go past 32 events when gathering
uncore events. Increase the amount to 1024 as that should provide some
amount of headroom.

Signed-off-by: Ian Rogers 
Signed-off-by: Namhyung Kim

perf bpf: Use __builtin_preserve_field_info for GCC compatibility

2025-10-02T17:57:07+00:00

When exploring building bpf_skel with GCC's BPF support, there was a
build failure because of bpf_core_field_exists vs the mem_hops bitfield:
```
 In file included from util/bpf_skel/sample_filter.bpf.c:6:
util/bpf_skel/sample_filter.bpf.c: In function 'perf_get_sample':
tools/perf/libbpf/include/bpf/bpf_core_read.h:169:42: error: cannot take address of bit-field 'mem_hops'
  169 | #define ___bpf_field_ref1(field)        (&(field))
      |                                          ^
tools/perf/libbpf/include/bpf/bpf_helpers.h:222:29: note: in expansion of macro '___bpf_field_ref1'
  222 | #define ___bpf_concat(a, b) a ## b
      |                             ^
tools/perf/libbpf/include/bpf/bpf_helpers.h:225:29: note: in expansion of macro '___bpf_concat'
  225 | #define ___bpf_apply(fn, n) ___bpf_concat(fn, n)
      |                             ^~~~~~~~~~~~~
tools/perf/libbpf/include/bpf/bpf_core_read.h:173:9: note: in expansion of macro '___bpf_apply'
  173 |         ___bpf_apply(___bpf_field_ref, ___bpf_narg(args))(args)
      |         ^~~~~~~~~~~~
tools/perf/libbpf/include/bpf/bpf_core_read.h:188:39: note: in expansion of macro '___bpf_field_ref'
  188 |         __builtin_preserve_field_info(___bpf_field_ref(field), BPF_FIELD_EXISTS)
      |                                       ^~~~~~~~~~~~~~~~
util/bpf_skel/sample_filter.bpf.c:167:29: note: in expansion of macro 'bpf_core_field_exists'
  167 |                         if (bpf_core_field_exists(data->mem_hops))
      |                             ^~~~~~~~~~~~~~~~~~~~~
cc1: error: argument is not a field access
```

___bpf_field_ref1 was adapted for GCC in 12bbcf8e840f40b82b02981e96e0a5fbb0703ea9
but the trick added for compatibility in 3a8b8fc3174891c4c12f5766d82184a82d4b2e3e
isn't compatible with that as an address is used as an argument.

Workaround this by calling __builtin_preserve_field_info directly as the
bpf_core_field_exists macro does, but without the ___bpf_field_ref use.

Co-developed-by: Andrew Pinski 
Signed-off-by: Andrew Pinski 
Signed-off-by: Sam James 
Acked-by: Yonghong Song 
Tested-by: Namhyung Kim 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Ian Rogers 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Link: https://gcc.gnu.org/PR121420
Signed-off-by: Arnaldo Carvalho de Melo

perf: Completely remove possibility to override MAX_NR_CPUS

2025-09-12T13:52:22+00:00

Commit 21b8732eb447 ("perf tools: Allow overriding MAX_NR_CPUS at
compile time") added the capability to override MAX_NR_CPUS. At
that time it was necessary to reduce the huge amount of RAM used
by static stats variables.

But this has been unnecessary since commit 6a1e2c5c2673 ("perf stat:
Remove a set of shadow stats static variables"), and
commit e8399d34d568 ("libperf cpumap: Hide/reduce scope of
MAX_NR_CPUS") broke the build in that case because it failed to
add the guard around the new definition of MAX_NR_CPUS.

So cleanup things and remove guards completely to officialise it
is not necessary anymore to override MAX_NR_CPUS.

Fixes: e8399d34d568d61c ("libperf cpumap: Hide/reduce scope of MAX_NR_CPUS")
Signed-off-by: Christophe Leroy 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Ian Rogers 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Leo Yan 
Cc: Mark Rutland 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: https://lore.kernel.org/all/8c8553387ebf904a9e5a93eaf643cb01164d9fb3.1736188471.git.christophe.leroy@csgroup.eu/
Signed-off-by: Arnaldo Carvalho de Melo