Date: Thu, 2 May 2024 11:06:10 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>, Steven Rostedt
 <rostedt@...dmis.org>, Florent Revest <revest@...omium.org>,
 linux-trace-kernel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
 Martin KaFai Lau <martin.lau@...ux.dev>, bpf <bpf@...r.kernel.org>, Sven
 Schnelle <svens@...ux.ibm.com>, Alexei Starovoitov <ast@...nel.org>, Jiri
 Olsa <jolsa@...nel.org>, Arnaldo Carvalho de Melo <acme@...nel.org>, Daniel
 Borkmann <daniel@...earbox.net>, Alan Maguire <alan.maguire@...cle.com>,
 Mark Rutland <mark.rutland@....com>, Peter Zijlstra <peterz@...radead.org>,
 Thomas Gleixner <tglx@...utronix.de>, Guo Ren <guoren@...nel.org>
Subject: Re: [PATCH v9 00/36] tracing: fprobe: function_graph:
 Multi-function graph and fprobe on fgraph

On Tue, 30 Apr 2024 09:29:40 -0700
Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:

> On Tue, Apr 30, 2024 at 6:32 AM Masami Hiramatsu <mhiramat@...nel.org> wrote:
> >
> > On Mon, 29 Apr 2024 13:25:04 -0700
> > Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
> >
> > > On Mon, Apr 29, 2024 at 6:51 AM Masami Hiramatsu <mhiramat@...nel.org> wrote:
> > > >
> > > > Hi Andrii,
> > > >
> > > > On Thu, 25 Apr 2024 13:31:53 -0700
> > > > Andrii Nakryiko <andrii.nakryiko@...il.com> 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@...nel.org>

Download attachment "perf-out-kretprobe-nopatch-raw-bpf" of type "application/octet-stream" (78480 bytes)

Download attachment "perf-out-kretprobe-patched-raw-bpf" of type "application/octet-stream" (78599 bytes)

Powered by blists - more mailing lists