Messages in this thread Patch in this message | | | From | Song Liu <> | Subject | Re: [PATCH v6 3/4] perf-stat: enable counting events for BPF programs | Date | Tue, 29 Dec 2020 18:42:18 +0000 |
| |
> On Dec 29, 2020, at 7:15 AM, Arnaldo Carvalho de Melo <acme@kernel.org> wrote: > > Em Mon, Dec 28, 2020 at 11:43:25PM +0000, Song Liu escreveu: >> >> >>> On Dec 28, 2020, at 12:11 PM, Arnaldo Carvalho de Melo <acme@kernel.org> wrote: >>> >>> Em Mon, Dec 28, 2020 at 09:40:53AM -0800, Song Liu escreveu: >>>> Introduce perf-stat -b option, which counts events for BPF programs, like: >>>> >>>> [root@localhost ~]# ~/perf stat -e ref-cycles,cycles -b 254 -I 1000 >>>> 1.487903822 115,200 ref-cycles >>>> 1.487903822 86,012 cycles >>>> 2.489147029 80,560 ref-cycles >>>> 2.489147029 73,784 cycles >>>> 3.490341825 60,720 ref-cycles >>>> 3.490341825 37,797 cycles >>>> 4.491540887 37,120 ref-cycles >>>> 4.491540887 31,963 cycles >>>> >>>> The example above counts cycles and ref-cycles of BPF program of id 254. >>>> This is similar to bpftool-prog-profile command, but more flexible. >>>> >>>> perf-stat -b creates per-cpu perf_event and loads fentry/fexit BPF >>>> programs (monitor-progs) to the target BPF program (target-prog). The >>>> monitor-progs read perf_event before and after the target-prog, and >>>> aggregate the difference in a BPF map. Then the user space reads data >>>> from these maps. >>>> >>>> A new struct bpf_counter is introduced to provide common interface that >>>> uses BPF programs/maps to count perf events. >>> >>> Segfaulting here: >>> >>> [root@five ~]# bpftool prog | grep tracepoint >>> 110: tracepoint name syscall_unaugme tag 57cd311f2e27366b gpl >>> 111: tracepoint name sys_enter_conne tag 3555418ac9476139 gpl >>> 112: tracepoint name sys_enter_sendt tag bc7fcadbaf7b8145 gpl >>> 113: tracepoint name sys_enter_open tag 0e59c3ac2bea5280 gpl >>> 114: tracepoint name sys_enter_opena tag 0baf443610f59837 gpl >>> 115: tracepoint name sys_enter_renam tag 24664e4aca62d7fa gpl >>> 116: tracepoint name sys_enter_renam tag 20093e51a8634ebb gpl >>> 117: tracepoint name sys_enter tag 0bc3fc9d11754ba1 gpl >>> 118: tracepoint name sys_exit tag 29c7ae234d79bd5c gpl >>> [root@five ~]# >>> [root@five ~]# gdb perf >>> GNU gdb (GDB) Fedora 10.1-2.fc33 >>> Reading symbols from perf... >>> (gdb) run stat -e instructions,cycles -b 113 -I 1000 >>> Starting program: /root/bin/perf stat -e instructions,cycles -b 113 -I 1000 >>> [Thread debugging using libthread_db enabled] >>> Using host libthread_db library "/lib64/libthread_db.so.1". >>> libbpf: elf: skipping unrecognized data section(9) .eh_frame >>> libbpf: elf: skipping relo section(15) .rel.eh_frame for section(9) .eh_frame >>> libbpf: elf: skipping unrecognized data section(9) .eh_frame >>> libbpf: elf: skipping relo section(15) .rel.eh_frame for section(9) .eh_frame >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0x000000000058d55b in bpf_program_profiler__read (evsel=0xc612c0) at util/bpf_counter.c:217 >>> 217 reading_map_fd = bpf_map__fd(skel->maps.accum_readings); >>> (gdb) bt >>> #0 0x000000000058d55b in bpf_program_profiler__read (evsel=0xc612c0) at util/bpf_counter.c:217 >>> #1 0x0000000000000000 in ?? () >>> (gdb) >>> >>> [acme@five perf]$ clang -v |& head -2 >>> clang version 11.0.0 (Fedora 11.0.0-2.fc33) >>> Target: x86_64-unknown-linux-gnu >>> [acme@five perf]$ >>> >>> Do you need any extra info? >> >> Hmm... I am not able to reproduce this. I am trying to setup an environment similar >> to fc33 (clang 11, etc.). Does this segfault every time, and on all programs? > > I'll try it with a BPF proggie attached to a kprobes, but here is > something else I noticed: > > [root@five perf]# export PYTHONPATH=/tmp/build/perf/python > [root@five perf]# tools/perf/python/twatch.py > Traceback (most recent call last): > File "/home/acme/git/perf/tools/perf/python/twatch.py", line 9, in <module> > import perf > ImportError: /tmp/build/perf/python/perf.cpython-39-x86_64-linux-gnu.so: undefined symbol: bpf_counter__destroy > [root@five perf]# perf test python > 19: 'import perf' in python : FAILED! > [root@five perf]# perf test -v python > 19: 'import perf' in python : > --- start --- > test child forked, pid 3198864 > python usage test: "echo "import sys ; sys.path.append('/tmp/build/perf/python'); import perf" | '/usr/bin/python3' " > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > ImportError: /tmp/build/perf/python/perf.cpython-39-x86_64-linux-gnu.so: undefined symbol: bpf_counter__destroy > test child finished with -1 > ---- end ---- > 'import perf' in python: FAILED! > [root@five perf]# > > This should be trivial, I hope, just add the new object file to > tools/perf/util/python-ext-sources, then do a 'perf test python', if it > fails, use 'perf test -v python' to see what is preventing the python > binding from loading.
I fixed the undefined bpf_counter__destroy. But this one looks trickier:
19: 'import perf' in python : --- start --- test child forked, pid 2714986 python usage test: "echo "import sys ; sys.path.append('python'); import perf" | '/bin/python2' " Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: XXXXX /tools/perf/python/perf.so: undefined symbol: bpf_map_update_elem
Given I already have:
diff --git i/tools/perf/util/python-ext-sources w/tools/perf/util/python-ext-sources index a9d9c142eb7c3..2cac55273eca2 100644 --- i/tools/perf/util/python-ext-sources +++ w/tools/perf/util/python-ext-sources @@ -35,3 +35,6 @@ util/symbol_fprintf.c util/units.c util/affinity.c util/rwsem.c +util/bpf_counter.c +../lib/bpf/bpf.c +../lib/bpf/libbpf.c
How should I fix this?
Thanks, Song
PS: I still cannot reproduce that segfault...
>
| |