On Thu, Mar 14, 2024 at 8:27 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Tue, Mar 12, 2024 at 6:53 PM 梦龙董 <dongmenglong.8@xxxxxxxxxxxxx> wrote: [......] > > What does "a hundred attachments max" means? Can't I > > trace thousands of kernel functions with a bpf program of > > tracing multi-link? > > I mean what time does it take to attach one program > to 100 fentry-s ? > What is the time for 1k and for 10k ? > > The kprobe multi test attaches to pretty much all funcs in > /sys/kernel/tracing/available_filter_functions > and it's fast enough to run in test_progs on every commit in bpf CI. > See get_syms() in prog_tests/kprobe_multi_test.c > > Can this new multi fentry do that? > and at what speed? > The answer will decide how applicable this api is going to be. > Generating different trampolines for every attach point > is an approach as well. Pls benchmark it too. I see. Creating plenty of trampolines does take a lot of time, and I'll do testing on it. > > > > > > > Let's step back. [......] > > For one trampoline to handle all attach points we might > need some arch support, but we can start simple. > Make btf_func_model with MAX_BPF_FUNC_REG_ARGS > by calling btf_distill_func_proto() with func==NULL. > And use that to build a trampoline. > > The challenge is how to use minimal number of trampolines > when bpf_progA is attached for func1, func2, func3 > and bpf_progB is attached to func3, func4, func5. > We'd still need 3 trampolines: > for func[12] to call bpf_progA, > for func3 to call bpf_progA and bpf_progB, > for func[45] to call bpf_progB. > > Jiri was trying to solve it in the past. His slides from LPC: > https://lpc.events/event/16/contributions/1350/attachments/1033/1983/plumbers.pdf > > Pls study them and his prior patchsets to avoid stepping on the same rakes.
