On Mon, 15 May 2023 12:24:07 -0700 Beau Belgrave <beaub@xxxxxxxxxxxxxxxxxxx> wrote: > > Beau, > > please provide a detailed explanation of your use case and how bpf helps. > > > > There are teams that have existing BPF programs that want to also pull > in data from user processes in addition to the data they already collect > from the kernel. > > We are also seeing a trend of teams wanting to drop buffering approaches > and move into non-buffered analysis of problems. An example is as soon > as a fault happens in a user-process, they would like the ability to see > what that thread has done, what the kernel did a bit before the error > (or other processes that have swapped in, etc). > > We also have needs to aggregate operation duration live, and as soon as > they deviate, trigger corrective actions. BPF is ideal for us to use for > aggregating data cheaply, comparing that to other kernel and user > processes, and then making a decision quickly on how to mitigate or flag > it. We are working with OpenTelemetry teams to make this work via > certain exporters in various languages (C#/C++/Rust). This is turning into a very productive discussion. Thank you Alexei and Beau for this. Beau, Could you possibly also add (in a separate patch), a simple use case of a BPF program that would be attached to some user event. Could be contrived. Perhaps supply a patch to ls.c[1] that adds a user event to where it reads a file type and the bpf program can do something special if the file belongs to the user. OK, I'm just pulling crazy ideas out of thin air! [1] https://github.com/coreutils/coreutils/blob/master/src/ls.c Could copy the ls with the user event to the samples directory for user events. It is GPL. -- Steve
