On Tue Apr 14, 2026 at 9:16 PM CEST, Alexei Starovoitov wrote: > On Tue, Apr 14, 2026 at 11:41 AM Alexis Lothoré > <[email protected]> wrote: >> >> On Tue Apr 14, 2026 at 4:36 PM CEST, Alexei Starovoitov wrote: >> > On Tue, Apr 14, 2026 at 6:13 AM Alexis Lothoré >> > <[email protected]> wrote: >> >> >> >> Hi Andrey, thanks for the prompt review !
[...] >> > No. The performance penalty will be too high. >> >> Since we are mentioning it, I did not consider yet any performance >> comparision/benchmarking (and I am not really familiar with usual bpf >> performance validation practices for new bpf features). Is there any >> existing test I should take a look at for this ? Maybe some specific >> benches in tools/testing/selftests/bpf/bench ? > > So far everything in bpf/bench/ measures bpf infra like > maps, kprobes, tracepoints, etc. > We don't have benchmarks for bpf programs. > So we don't know how well JITs are generating code > and how much inlining done by the verifier, JITs actually helps. > > Puranjay is working on creating a SPECint like set of benchmarks. > > For this kasan work we should make the best decisions from > performance point of view, like not wasting unnecessary call > and not saving unnecessary registers. btw in the other patch > I think you can skip saving of r10 and r11. Noted, I'll do some checks and tests without those two. > But we cannot quantify yet that avoiding extra call gives us N%. > > You can micro-benchmark, of course, but gotta be careful > interpreting the results. It might be too easy to get into > thinking that JIT must inline __asan_load() for the sake of performance. Ok, interesting, thanks for those details Alexis -- Alexis Lothoré, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
