> On Dec 29, 2020, at 7:15 AM, Arnaldo Carvalho de Melo <a...@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 <a...@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...
>
