Hi Steven,
Thanks for your explanation about ftrace ring buffer. Also thanks to
Shung-Hsi for the discussion.
Here are some features of ftrace buffer that I'm not sure if they are
right. Could you please tell me if my understandings correct?
(1) When reading and writing occur concurrently:
(a) If reader is faster than writer, the reader cannot get the page
which is still being written, which means the reader cannot get the data
immediately of one-page length in the worst case.
(b) If writer is faster than reader, the only race between them is
when reader is doing swap while writer wraps in overwrite mode. But if
the reader has finished swapping, the writer can wrap safely, because
the reader page if already out of the buffer page list.
(2) As the per-cpu buffer list is dynamic with reader page moves, we
cannot do mmap to expose the buffer to user. Users can consume at most
one page at a time.
(3) The wake-up behavior is controllable. If there is no waiter at all,
no overhead will be induced because of waking up.
Thanks.
On 2023/12/19 21:38, Steven Rostedt wrote:
On Tue, 19 Dec 2023 14:23:59 +0800
Shung-Hsi Yu <shung-hsi.yu@xxxxxxxx> 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
