kernel/linux.git/tools/perf/util/bpf_skel, branch v6.4

perf bpf filter: Fix a broken perf sample data naming for BPF CO-RE

2023-05-26T18:21:08+00:00

BPF CO-RE requires 3 underscores for the ignored suffix rule but it mistakenly used only 2. Let's fix it. Fixes: 3a8b8fc3174891c4 ("perf bpf filter: Support pre-5.16 kernels where 'mem_hops' isn't in 'union perf_mem_data_src'") Signed-off-by: Namhyung Kim Acked-by: Andrii Nakryiko Acked-by: John Fastabend Cc: Adrian Hunter Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Peter Zijlstra Cc: Song Liu Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20230525000307.3202449-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf lock contention: Add empty 'struct rq' to satisfy libbpf 'runqueue' type verification

2023-05-10T19:15:04+00:00

If 'struct rq' isn't defined in lock_contention.bpf.c then the type for the 'runqueue' variable ends up being a forward declaration (BTF_KIND_FWD) while the kernel has it defined (BTF_KIND_STRUCT). This makes libbpf decide it has incompatible types and then fails to load the BPF skeleton: # perf lock con -ab sleep 1 libbpf: extern (var ksym) 'runqueues': incompatible types, expected [95] fwd rq, but kernel has [55509] struct rq libbpf: failed to load object 'lock_contention_bpf' libbpf: failed to load BPF skeleton 'lock_contention_bpf': -22 Failed to load lock-contention BPF skeleton lock contention BPF setup failed # Add it as an empty struct to satisfy that type verification: # perf lock con -ab sleep 1 contended total wait max wait avg wait type caller 2 50.64 us 25.38 us 25.32 us spinlock tick_do_update_jiffies64+0x25 1 26.18 us 26.18 us 26.18 us spinlock tick_do_update_jiffies64+0x25 # Committer notes: Extracted from a larger patch as Namhyung had already fixed the other issues in e53de7b65a3ca59a ("perf lock contention: Fix struct rq lock access"). Signed-off-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Changbin Du Cc: Hao Luo Cc: Ian Rogers Cc: Namhyung Kim Cc: Song Liu Cc: Stephane Eranian Cc: Yang Jihong Link: https://lore.kernel.org/lkml/ZFVqeKLssg7uzxzI@krava Signed-off-by: Arnaldo Carvalho de Melo

perf bpf skels: Make vmlinux.h use bpf.h and perf_event.h in source directory

2023-05-10T17:20:49+00:00

Currently, vmlinux.h uses the bpf.h and perf_event.h header files in the system path. If the header files in compilation environment are old, compilation may fail. For example: /home/yangjihong/linux/tools/perf/util/bpf_skel/.tmp/../vmlinux.h:151:27: error: field has incomplete type 'union perf_sample_weight' union perf_sample_weight weight; Use the bpf.h and perf_event.h files in the source code directory to avoid compilation compatibility problems. Signed-off-by: Yang Jihong Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Peter Zijlstra Cc: Tom Rix Link: https://lore.kernel.org/r/20230510064401.225051-1-yangjihong1@huawei.com Signed-off-by: Arnaldo Carvalho de Melo

perf bpf skels: Stop using vmlinux.h generated from BTF, use subset of used structs + CO-RE

2023-05-05T22:18:39+00:00

Linus reported a build break due to using a vmlinux without a BTF elf section to generate the vmlinux.h header with bpftool for use in the BPF tools in tools/perf/util/bpf_skel/*.bpf.c. Instead add a vmlinux.h file with the structs needed with the fields the tools need, marking the structs with __attribute__((preserve_access_index)), so that libbpf's CO-RE code can fixup the struct field offsets. In some cases the vmlinux.h file that was being generated by bpftool from the kernel BTF information was not needed at all, just including linux/bpf.h, sometimes linux/perf_event.h was enough as non-UAPI types were not being used. To keep te patch small, include those UAPI headers from the trimmed down vmlinux.h file, that then provides the tools with just the structs and the subset of its fields needed for them. Testing it: # perf lock contention -b find / > /dev/null ^C contended total wait max wait avg wait type caller 7 53.59 us 10.86 us 7.66 us rwlock:R start_this_handle+0xa0 2 30.35 us 21.99 us 15.17 us rwsem:R iterate_dir+0x52 1 9.04 us 9.04 us 9.04 us rwlock:W start_this_handle+0x291 1 8.73 us 8.73 us 8.73 us spinlock raw_spin_rq_lock_nested+0x1e # # perf lock contention -abl find / > /dev/null ^C contended total wait max wait avg wait address symbol 1 262.96 ms 262.96 ms 262.96 ms ffff8e67502d0170 (mutex) 12 244.24 us 39.91 us 20.35 us ffff8e6af56f8070 mmap_lock (rwsem) 7 30.28 us 6.85 us 4.33 us ffff8e6c865f1d40 rq_lock (spinlock) 3 7.42 us 4.03 us 2.47 us ffff8e6c864b1d40 rq_lock (spinlock) 2 3.72 us 2.19 us 1.86 us ffff8e6c86571d40 rq_lock (spinlock) 1 2.42 us 2.42 us 2.42 us ffff8e6c86471d40 rq_lock (spinlock) 4 2.11 us 559 ns 527 ns ffffffff9a146c80 rcu_state (spinlock) 3 1.45 us 818 ns 482 ns ffff8e674ae8384c (rwlock) 1 870 ns 870 ns 870 ns ffff8e68456ee060 (rwlock) 1 663 ns 663 ns 663 ns ffff8e6c864f1d40 rq_lock (spinlock) 1 573 ns 573 ns 573 ns ffff8e6c86531d40 rq_lock (spinlock) 1 472 ns 472 ns 472 ns ffff8e6c86431740 (spinlock) 1 397 ns 397 ns 397 ns ffff8e67413a4f04 (spinlock) # # perf test offcpu 95: perf record offcpu profiling tests : Ok # # perf kwork latency --use-bpf Starting trace, Hit to stop and report ^C Kwork Name | Cpu | Avg delay | Count | Max delay | Max delay start | Max delay end | -------------------------------------------------------------------------------------------------------------------------------- (w)flush_memcg_stats_dwork | 0000 | 1056.212 ms | 2 | 2112.345 ms | 550113.229573 s | 550115.341919 s | (w)toggle_allocation_gate | 0000 | 10.144 ms | 62 | 416.389 ms | 550113.453518 s | 550113.869907 s | (w)0xffff8e6748e28080 | 0002 | 0.623 ms | 1 | 0.623 ms | 550110.989841 s | 550110.990464 s | (w)vmstat_shepherd | 0000 | 0.586 ms | 10 | 2.828 ms | 550111.971536 s | 550111.974364 s | (w)vmstat_update | 0007 | 0.363 ms | 5 | 1.634 ms | 550113.222520 s | 550113.224154 s | (w)vmstat_update | 0000 | 0.324 ms | 10 | 2.827 ms | 550111.971526 s | 550111.974354 s | (w)0xffff8e674c5f4a58 | 0002 | 0.102 ms | 5 | 0.134 ms | 550110.989839 s | 550110.989972 s | (w)psi_avgs_work | 0001 | 0.086 ms | 3 | 0.107 ms | 550114.957852 s | 550114.957959 s | (w)psi_avgs_work | 0000 | 0.079 ms | 5 | 0.100 ms | 550118.605668 s | 550118.605768 s | (w)kfree_rcu_monitor | 0006 | 0.079 ms | 1 | 0.079 ms | 550110.925821 s | 550110.925900 s | (w)psi_avgs_work | 0004 | 0.079 ms | 1 | 0.079 ms | 550109.581835 s | 550109.581914 s | (w)psi_avgs_work | 0001 | 0.078 ms | 1 | 0.078 ms | 550109.197809 s | 550109.197887 s | (w)psi_avgs_work | 0002 | 0.077 ms | 5 | 0.086 ms | 550110.669819 s | 550110.669905 s | # strace -e bpf -o perf-stat-bpf-counters.output perf stat -e cycles --bpf-counters sleep 1 Performance counter stats for 'sleep 1': 6,197,983 cycles 1.003922848 seconds time elapsed 0.000000000 seconds user 0.002032000 seconds sys # head -7 perf-stat-bpf-counters.output bpf(BPF_OBJ_GET, {pathname="/sys/fs/bpf/perf_attr_map", bpf_fd=0, file_flags=0}, 16) = 3 bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=3, info_len=88, info=0x7ffcead64990}}, 16) = 0 bpf(BPF_MAP_LOOKUP_ELEM, {map_fd=3, key=0x24129e0, value=0x7ffcead65a48, flags=BPF_ANY}, 32) = 0 bpf(BPF_LINK_GET_FD_BY_ID, {link_id=1252}, 12) = -1 ENOENT (No such file or directory) bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_SOCKET_FILTER, insn_cnt=2, insns=0x7ffcead65780, license="GPL", log_level=0, log_size=0, log_buf=NULL, kern_version=KERNEL_VERSION(0, 0, 0), prog_flags=0, prog_name="", prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS, prog_btf_fd=0, func_info_rec_size=0, +func_info=NULL, func_info_cnt=0, line_info_rec_size=0, line_info=NULL, line_info_cnt=0, attach_btf_id=0, attach_prog_fd=0}, 116) = 4 bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_SOCKET_FILTER, insn_cnt=2, insns=0x7ffcead65920, license="GPL", log_level=0, log_size=0, log_buf=NULL, kern_version=KERNEL_VERSION(0, 0, 0), prog_flags=0, prog_name="", prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS, prog_btf_fd=0, func_info_rec_size=0, +func_info=NULL, func_info_cnt=0, line_info_rec_size=0, line_info=NULL, line_info_cnt=0, attach_btf_id=0, attach_prog_fd=0, fd_array=NULL}, 128) = 4 bpf(BPF_BTF_LOAD, {btf="\237\353\1\0\30\0\0\0\0\0\0\0\20\0\0\0\20\0\0\0\5\0\0\0\1\0\0\0\0\0\0\1"..., btf_log_buf=NULL, btf_size=45, btf_log_size=0, btf_log_level=0}, 28) = 4 # Reported-by: Linus Torvalds Suggested-by: Andrii Nakryiko Tested-by: Namhyung Kim Tested-by: Song Liu Cc: Adrian Hunter Cc: Alexei Starovoitov Cc: Ian Rogers Cc: Jiri Olsa Co-developed-by: Jiri Olsa Link: https://lore.kernel.org/lkml/ZFU1PJrn8YtHIqno@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf lock contention: Rework offset calculation with BPF CO-RE

2023-05-02T11:36:14+00:00

It seems BPF CO-RE reloc doesn't work well with the pattern that gets the field-offset only. Use offsetof() to make it explicit so that the compiler would generate the correct code. Fixes: 0c1228486befa3d6 ("perf lock contention: Support pre-5.14 kernels") Signed-off-by: Namhyung Kim Acked-by: Ian Rogers Cc: Adrian Hunter Cc: Andrii Nakryiko Cc: Hao Luo Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Peter Zijlstra Cc: Song Liu Cc: bpf@vger.kernel.org Co-developed-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20230427234833.1576130-2-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf lock contention: Fix struct rq lock access

2023-05-02T11:36:14+00:00

The BPF CO-RE's ignore suffix rule requires three underscores. Otherwise it'd fail like below: $ sudo perf lock contention -ab libbpf: prog 'collect_lock_syms': BPF program load failed: Invalid argument libbpf: prog 'collect_lock_syms': -- BEGIN PROG LOAD LOG -- reg type unsupported for arg#0 function collect_lock_syms#380 ; int BPF_PROG(collect_lock_syms) 0: (b7) r6 = 0 ; R6_w=0 1: (b7) r7 = 0 ; R7_w=0 2: (b7) r9 = 1 ; R9_w=1 3: failed to resolve CO-RE relocation [381] struct rq__new.__lock (0:0 @ offset 0) Fixes: 0c1228486befa3d6 ("perf lock contention: Support pre-5.14 kernels") Signed-off-by: Namhyung Kim Acked-by: Ian Rogers Cc: Adrian Hunter Cc: Andrii Nakryiko Cc: Hao Luo Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Peter Zijlstra Cc: Song Liu Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20230427234833.1576130-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf bpf filter: Support pre-5.16 kernels where 'mem_hops' isn't in 'union perf_mem_data_src'

2023-04-10T21:57:17+00:00

The 'mem_hops' bits were added in 5.16 with no prior equivalent. Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Peter Zijlstra Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20230408055208.1283832-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo

perf lock contention: Support pre-5.14 kernels

2023-04-10T21:55:12+00:00

'struct rq's member '__lock' was renamed from 'lock' in 5.14. Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Peter Zijlstra Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20230408055208.1283832-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo

perf lock contention: Do not try to update if hash map is full

2023-04-07T00:53:54+00:00

It doesn't delete data in the task_data and lock_stat maps. The data is kept there until it's consumed by userspace at the end. But it calls bpf_map_update_elem() again and again, and the data will be discarded if the map is full. This is not good. Worse, in the bpf_map_update_elem(), it keeps trying to get a new node even if the map was full. I guess it makes sense if it deletes some node like in the tstamp map (that's why I didn't make the change there). In a pre-allocated hash map, that means it'd iterate all CPU to check the freelist. And it has a bad performance impact on large machines. I've checked it on my 64 CPU machine with this. $ perf bench sched messaging -g 1000 # Running 'sched/messaging' benchmark: # 20 sender and receiver processes per group # 1000 groups == 40000 processes run Total time: 2.825 [sec] And I used the task mode, so that it can guarantee the map is full. The default map entry size is 16K and this workload has 40K tasks. Before: $ sudo ./perf lock con -abt -E3 -- perf bench sched messaging -g 1000 # Running 'sched/messaging' benchmark: # 20 sender and receiver processes per group # 1000 groups == 40000 processes run Total time: 11.299 [sec] contended total wait max wait avg wait pid comm 19284 3.51 s 3.70 ms 181.91 us 1305863 sched-messaging 243 84.09 ms 466.67 us 346.04 us 1336608 sched-messaging 177 66.35 ms 12.08 ms 374.88 us 1220416 node For some reason, it didn't report the data failures. But you can see the total time in the workload is increased a lot (2.8 -> 11.3). If it fails early when the map is full, it goes back to normal. After: $ sudo ./perf lock con -abt -E3 -- perf bench sched messaging -g 1000 # Running 'sched/messaging' benchmark: # 20 sender and receiver processes per group # 1000 groups == 40000 processes run Total time: 3.044 [sec] contended total wait max wait avg wait pid comm 18743 591.92 ms 442.96 us 31.58 us 1431454 sched-messaging 51 210.64 ms 207.45 ms 4.13 ms 1468724 sched-messaging 81 68.61 ms 65.79 ms 847.07 us 1463183 sched-messaging === output for debug === bad: 1164137, total: 2253341 bad rate: 51.66 % histogram of failure reasons task: 0 stack: 0 time: 0 data: 1164137 Signed-off-by: Namhyung Kim Acked-by: Ian Rogers Cc: Adrian Hunter Cc: Hao Luo Cc: Ingo Molnar Cc: Jiri Olsa Cc: Juri Lelli Cc: Peter Zijlstra Cc: Song Liu Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20230406210611.1622492-2-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf lock contention: Add data failure stat

2023-04-07T00:52:31+00:00

It's possible to fail to update the data when the lock_stat map is full. We should check that case and show the number at the end. $ sudo ./perf lock con -ablv -E3 -- ./perf bench sched messaging ... contended total wait max wait avg wait address symbol 6157 208.48 ms 69.29 us 33.86 us ffff934c001c1f00 (spinlock) 4030 72.04 ms 61.84 us 17.88 us ffff934c000415c0 (spinlock) 3201 50.30 ms 47.73 us 15.71 us ffff934c2eead850 (spinlock) === output for debug === bad: 0, total: 13388 bad rate: 0.00 % histogram of failure reasons task: 0 stack: 0 time: 0 data: 0 <----- added Signed-off-by: Namhyung Kim Acked-by: Ian Rogers Cc: Adrian Hunter Cc: Hao Luo Cc: Ingo Molnar Cc: Jiri Olsa Cc: Juri Lelli Cc: Peter Zijlstra Cc: Song Liu Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20230406210611.1622492-2-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo