On Tue, Feb 11, 2020 at 04:32:23PM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Feb 10, 2020 at 05:17:51PM +0100, Jiri Olsa escreveu: > > On Mon, Feb 10, 2020 at 04:51:08PM +0100, Björn Töpel wrote: > > > On Sat, 8 Feb 2020 at 16:42, Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > > > this patchset adds trampoline and dispatcher objects > > > > to be visible in /proc/kallsyms. The last patch also > > > > adds sorting for all bpf objects in /proc/kallsyms. > > > > Thanks for working on this! > > > > I'm probably missing something with my perf setup; I've applied your > > > patches, and everything seem to work fine from an kallsyms > > > perspective: > > > > # grep bpf_dispatcher_xdp /proc/kallsyms > > > ... > > > ffffffffc0511000 t bpf_dispatcher_xdp [bpf] > > > > > > However, when I run > > > # perf top > > > > > > I still see the undecorated one: > > > 0.90% [unknown] [k] 0xffffffffc0511037 > > > > > > Any ideas? > > > yea strange.. it should be picked up from /proc/kallsyms as > > fallback if there's no other source, I'll check on that > > (might be the problem with perf depending on address going > > only higher in /proc/kallsyms, while bpf symbols are at the > > end and start over from the lowest bpf address) > > > > anyway, in perf we enumerate bpf_progs via the perf events > > PERF_BPF_EVENT_PROG_LOAD,PERF_BPF_EVENT_PROG_UNLOAD interface > > together with PERF_RECORD_KSYMBOL_TYPE_BPF events > > > > we might need to add something like: > > PERF_RECORD_KSYMBOL_TYPE_BPF_TRAMPOLINE > > PERF_RECORD_KSYMBOL_TYPE_BPF_DISPATCHER > > > > to notify about the area, I'll check on that > > > > however the /proc/kallsyms fallback should work in any > > case.. thanks for report ;-) > > We should by now move kallsyms to be the preferred source of symbols, > not vmlinux, right? > > Perhaps what is happening is: > > [root@quaco ~]# strace -f -e open,openat -o /tmp/bla perf top > [root@quaco ~]# grep vmlinux /tmp/bla > 11013 openat(AT_FDCWD, "vmlinux", O_RDONLY) = -1 ENOENT (No such file or directory) > 11013 openat(AT_FDCWD, "/boot/vmlinux", O_RDONLY) = -1 ENOENT (No such file or directory) > 11013 openat(AT_FDCWD, "/boot/vmlinux-5.5.0+", O_RDONLY) = -1 ENOENT (No such file or directory) > 11013 openat(AT_FDCWD, "/usr/lib/debug/boot/vmlinux-5.5.0+", O_RDONLY) = -1 ENOENT (No such file or directory) > 11013 openat(AT_FDCWD, "/lib/modules/5.5.0+/build/vmlinux", O_RDONLY) = 152 > [root@quaco ~]# > > I.e. it is using vmlinux for resolving symbols and he should try with: > > [root@quaco ~]# strace -f -e open,openat -o /tmp/bla perf top --ignore-vmlinux > [root@quaco ~]# perf top -h vmlinux > > Usage: perf top [<options>] > > -k, --vmlinux <file> vmlinux pathname > --ignore-vmlinux don't load vmlinux even if found > > [root@quaco ~]# grep vmlinux /tmp/bla > [root@quaco ~]# > > Historically vmlinux was preferred because it contains function sizes, > but with all these out of the blue symbols, we need to prefer starting > with /proc/kallsyms and, as we do now, continue getting updates via > PERF_RECORD_KSYMBOL. > > Humm, but then trampolines don't generate that, right? Or does it? If it > doesn't, then we will know about just the trampolines in place when the > record/top session starts, reparsing /proc/kallsyms periodically seems > excessive? I plan to extend the KSYMBOL interface to contain trampolines/dispatcher data, plus we could do some inteligent fallback to /proc/kallsyms in case vmlinux won't have anything jirka
