lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 2 Aug 2020 22:10:31 -0700 From: Andrii Nakryiko <andrii.nakryiko@...il.com> To: Song Liu <songliubraving@...com> Cc: open list <linux-kernel@...r.kernel.org>, bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Kernel Team <Kernel-team@...com>, john fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...omium.org>, Jesper Dangaard Brouer <brouer@...hat.com>, Daniel Xu <dlxu@...com> Subject: Re: [PATCH bpf-next 5/5] selftests/bpf: add benchmark for uprobe vs. user_prog On Sun, Aug 2, 2020 at 9:47 PM Song Liu <songliubraving@...com> wrote: > > > > On Aug 2, 2020, at 6:51 PM, Andrii Nakryiko <andrii.nakryiko@...il.com> wrote: > > > > On Sat, Aug 1, 2020 at 1:50 AM Song Liu <songliubraving@...com> wrote: > >> > >> Add a benchmark to compare performance of > >> 1) uprobe; > >> 2) user program w/o args; > >> 3) user program w/ args; > >> 4) user program w/ args on random cpu. > >> > > > > Can you please add it to the existing benchmark runner instead, e.g., > > along the other bench_trigger benchmarks? No need to re-implement > > benchmark setup. And also that would also allow to compare existing > > ways of cheaply triggering a program vs this new _USER program? > > Will try. > > > > > If the performance is not significantly better than other ways, do you > > think it still makes sense to add a new BPF program type? I think > > triggering KPROBE/TRACEPOINT from bpf_prog_test_run() would be very > > nice, maybe it's possible to add that instead of a new program type? > > Either way, let's see comparison with other program triggering > > mechanisms first. > > Triggering KPROBE and TRACEPOINT from bpf_prog_test_run() will be useful. > But I don't think they can be used instead of user program, for a couple > reasons. First, KPROBE/TRACEPOINT may be triggered by other programs > running in the system, so user will have to filter those noise out in > each program. Second, it is not easy to specify CPU for KPROBE/TRACEPOINT, > while this feature could be useful in many cases, e.g. get stack trace > on a given CPU. > Right, it's not as convenient with KPROBE/TRACEPOINT as with the USER program you've added specifically with that feature in mind. But if you pin user-space thread on the needed CPU and trigger kprobe/tp, then you'll get what you want. As for the "noise", see how bench_trigger() deals with that: it records thread ID and filters everything not matching. You can do the same with CPU ID. It's not as automatic as with a special BPF program type, but still pretty simple, which is why I'm still deciding (for myself) whether USER program type is necessary :) > Thanks, > Song
Powered by blists - more mailing lists