On Thu, Mar 14, 2024 at 8:27 AM Alexei Starovoitov alexei.starovoitov@gmail.com wrote:
On Tue, Mar 12, 2024 at 6:53 PM 梦龙董 dongmenglong.8@bytedance.com 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/plumber...
Pls study them and his prior patchsets to avoid stepping on the same rakes.