On Tue, 30 Apr 2024 09:29:40 -0700 Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > On Tue, Apr 30, 2024 at 6:32 AM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > > > On Mon, 29 Apr 2024 13:25:04 -0700 > > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > On Mon, Apr 29, 2024 at 6:51 AM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > > > > > > > Hi Andrii, > > > > > > > > On Thu, 25 Apr 2024 13:31:53 -0700 > > > > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > > > > > Hey Masami, > > > > > > > > > > I can't really review most of that code as I'm completely unfamiliar > > > > > with all those inner workings of fprobe/ftrace/function_graph. I left > > > > > a few comments where there were somewhat more obvious BPF-related > > > > > pieces. > > > > > > > > > > But I also did run our BPF benchmarks on probes/for-next as a baseline > > > > > and then with your series applied on top. Just to see if there are any > > > > > regressions. I think it will be a useful data point for you. > > > > > > > > Thanks for testing! > > > > > > > > > > > > > > You should be already familiar with the bench tool we have in BPF > > > > > selftests (I used it on some other patches for your tree). > > > > > > > > What patches we need? > > > > > > > > > > You mean for this `bench` tool? They are part of BPF selftests (under > > > tools/testing/selftests/bpf), you can build them by running: > > > > > > $ make RELEASE=1 -j$(nproc) bench > > > > > > After that you'll get a self-container `bench` binary, which has all > > > the self-contained benchmarks. > > > > > > You might also find a small script (benchs/run_bench_trigger.sh inside > > > BPF selftests directory) helpful, it collects final summary of the > > > benchmark run and optionally accepts a specific set of benchmarks. So > > > you can use it like this: > > > > > > $ benchs/run_bench_trigger.sh kprobe kprobe-multi > > > kprobe : 18.731 ± 0.639M/s > > > kprobe-multi : 23.938 ± 0.612M/s > > > > > > By default it will run a wider set of benchmarks (no uprobes, but a > > > bunch of extra fentry/fexit tests and stuff like this). > > > > origin: > > # benchs/run_bench_trigger.sh > > kretprobe : 1.329 ± 0.007M/s > > kretprobe-multi: 1.341 ± 0.004M/s > > # benchs/run_bench_trigger.sh > > kretprobe : 1.288 ± 0.014M/s > > kretprobe-multi: 1.365 ± 0.002M/s > > # benchs/run_bench_trigger.sh > > kretprobe : 1.329 ± 0.002M/s > > kretprobe-multi: 1.331 ± 0.011M/s > > # benchs/run_bench_trigger.sh > > kretprobe : 1.311 ± 0.003M/s > > kretprobe-multi: 1.318 ± 0.002M/s s > > > > patched: > > > > # benchs/run_bench_trigger.sh > > kretprobe : 1.274 ± 0.003M/s > > kretprobe-multi: 1.397 ± 0.002M/s > > # benchs/run_bench_trigger.sh > > kretprobe : 1.307 ± 0.002M/s > > kretprobe-multi: 1.406 ± 0.004M/s > > # benchs/run_bench_trigger.sh > > kretprobe : 1.279 ± 0.004M/s > > kretprobe-multi: 1.330 ± 0.014M/s > > # benchs/run_bench_trigger.sh > > kretprobe : 1.256 ± 0.010M/s > > kretprobe-multi: 1.412 ± 0.003M/s > > > > Hmm, in my case, it seems smaller differences (~3%?). > > I attached perf report results for those, but I don't see large difference. > > I ran my benchmarks on bare metal machine (and quite powerful at that, > you can see my numbers are almost 10x of yours), with mitigations > disabled, no retpolines, etc. If you have any of those mitigations it > might result in smaller differences, probably. If you are running > inside QEMU/VM, the results might differ significantly as well. I ran it on my bare metal machines again, but could not find any difference between them. But I think I enabled intel mitigations on, so it might make a difference from your result. Can you run the benchmark with perf record? If there is such differences, there should be recorded. e.g. # perf record -g -o perf.data-kretprobe-nopatch-raw-bpf -- bench -w2 -d5 -a trig-kretprobe # perf report -G -i perf.data-kretprobe-nopatch-raw-bpf -k $VMLINUX --stdio > perf-out-kretprobe-nopatch-raw-bpf I attached the results in my side. The interesting point is, the functions int the result are not touched by this series. Thus there may be another reason if you see the kretprobe regression. Thank you, -- Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
Attachment:
perf-out-kretprobe-nopatch-raw-bpf
Description: Binary data
Attachment:
perf-out-kretprobe-patched-raw-bpf
Description: Binary data
