Re: Question about bpf perfbuf/ringbuf: pinned in backend with overwriting

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 19 Dec 2023 14:23:59 +0800
Shung-Hsi Yu <shung-hsi.yu@suse.com> wrote:

> Curious whether it is possible to reuse ftrace's trace buffer instead
> (or it's underlying ring buffer implementation at
> kernel/trace/ring_buffer.c). AFAICT it satisfies both requirements that
> Philo stated: (1) no need for user process as the buffer is accessible
> through tracefs, and (2) has an overwrite mode.

Yes, the ftrace ring-buffer was in fact designed for the above use case.

> 
> Further more, a natural feature request that would come after
> overwriting support would be snapshotting, and that has already been
> covered in ftrace.

Yes, it has that too.

> 
> Note: technically BPF program could already write to ftrace's trace
> buffer with the bpf_trace_vprintk() helper, but that goes through string
> formatting and only allows writing into to the global buffer.

When eBPF was first being developed, Alexei told me he tried the ftrace
ring buffer, and he said the filtering was too slow. That's because it
would always write into the ring buffer and then try to discard it after
the fact, which required a few cmpxchg to synchronize. He decided that the
perf ring buffer was a better fit for this.

That was solved with this: 0fc1b09ff1ff4 ("tracing: Use temp buffer when
filtering events") Which makes the filtering similar to perf as perf always
copies events to a temporary buffer first.

It still falls back to writing directly into the ring buffer if the temp
buffer is currently being used by another event on the same CPU.

Note that the perf ring buffer was designed for profiling (taking
intermediate traces) and tightly coupled to have a reader. Whereas the
ftrace ring buffer was designed for high speed constant tracing, with or
without a reader.

-- Steve