On Tue, Mar 26, 2024 at 9:50 AM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > Fix in the sense to adjust or add another generic > PERF_SAMPLE_BRANCH_xxx value? Or you mean stop using --lbr=any mode? > > > I suspect retsnoop quality won't suffer if ARCH_LBR_REL_JMP is disabled. > > To figure out the path to return in the code > > ARCH_LBR_JCC | > > ARCH_LBR_REL_CALL | > > ARCH_LBR_IND_CALL | > > ARCH_LBR_RETURN > > > > might be good enough and there won't be a need to do > > inling in odd places just to avoid tail jmp. > > retsnoop supports all modes perf exposes generically (see [0]), I > believe I tried all of them and keep gravitating back to --lbr=any as > most useful, unfortunately. I mean to use PERF_SAMPLE_BRANCH_ANY_CALL | PERF_SAMPLE_BRANCH_COND which I suspect will exclude ARCH_LBR_REL_JMP and will avoid counting normal goto-s. > I'm missing how we can get away from having a per-CPU buffer. LBRs on > different CPU cores are completely independent and one BPF prog > attachment can be simultaneously running on many CPUs. > > Or do you mean per-CPU allocation for each attach point? > > We can do LBR capture before migrate_disable calls and still have > correct data most of the time (hopefully), though, so yeah, it can be > another improvement (but with inlining of those two BPF helpers I'm > not sure we have to do this just yet). I meant 32*24 buffer per attachment. Doing per-attachment per-cpu might not scale? It's certainly cleaner with per-cpu though. With a single per-attach buffer the assumption was that the different cpus will likely take the same path towards that kprobe. retsnoop doesn't care which cpu it collected that stack trace from. It cares about the code path and it will be there. We can make the whole thing configurable. bpf_link_attach would specify a buffer or per-cpu or a buffer right in the bpf map array that should be used to store the lbr trace.
