On Thu, Sep 24, 2026 at 10:27:55AM +0900, Masami Hiramatsu wrote: > On Tue, 22 Sep 2026 10:41:30 +0100 > Vincent Donnefort <[email protected]> wrote: > > > On Mon, Sep 21, 2026 at 07:30:45PM +0800, Xiang Gao wrote: > > > Report the memory consumed by the tracing ring buffers, rather than the > > > usable data capacity exposed by buffer_size_kb. Android low-memory > > > diagnostics need this to attribute the memory used by tracing when > > > calculating lost RAM. > > > > > > The buffers can be spread across the global trace array, dynamically > > > created instances, and snapshot buffers. Userspace currently has to > > > discover and sum every instance, and snapshot memory is not exposed by > > > the per-instance totals. > > > > > > Add a trace_stats directory with memory_usage_kb reporting: > > > > > > buffers: > > > snapshot_buffers: > > > > > > covering the global trace array, all instances, and the bootstrapping > > > temp_buffer across all CPUs. > > > > > > The values account for the full pages backing the data sub-buffers and > > > reader page, plus the cached read page and mmap metadata page when > > > present. Slab-allocated ring-buffer metadata is not included, as it is > > > already reported through Slab and would be double-counted when > > > subtracting tracing memory from lost RAM. Remote buffers, whose pages > > > are externally owned, report zero. > > > > For the next version, it is good practice to __not__ in-reply-to with > > previous > > version. > > > > Indeed. This is hard to find which is the latest version. > > > > > > > Signed-off-by: Xiang Gao <[email protected]> > > > --- > > > Documentation/trace/ftrace.rst | 12 +++++ > > > include/linux/ring_buffer.h | 1 + > > > kernel/trace/ring_buffer.c | 41 +++++++++++++++ > > > kernel/trace/trace.c | 95 ++++++++++++++++++++++++++++++++++ > > > 4 files changed, 149 insertions(+) > > > > > > diff --git a/Documentation/trace/ftrace.rst > > > b/Documentation/trace/ftrace.rst > > > index 7261f25f8b4b..99ddfe26b7cd 100644 > > > --- a/Documentation/trace/ftrace.rst > > > +++ b/Documentation/trace/ftrace.rst > > > @@ -218,6 +218,18 @@ of ftrace. Here is a list of some of the key files: > > > > > > This displays the total combined size of all the trace buffers. > > > > > > + trace_stats/memory_usage_kb: > > > + > > > + This reports the memory consumed by the ring buffers, as opposed to > > > + the usable data capacity shown by buffer_size_kb. The value covers the > > > + main and snapshot buffers of the global trace array and all tracing > > > + instances. It does not include slab-allocated ring-buffer metadata. > > > + > > > + Output:: > > > + > > > + buffers: ... > > > + snapshot_buffers: ... > > > + > > > buffer_subbuf_size_kb: > > > > > > This sets or displays the sub buffer size. The ring buffer is broken up > > > diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h > > > index eac3e9080c3c..96b99e6757d4 100644 > > > --- a/include/linux/ring_buffer.h > > > +++ b/include/linux/ring_buffer.h > > > @@ -167,6 +167,7 @@ int ring_buffer_iter_empty(struct ring_buffer_iter > > > *iter); > > > bool ring_buffer_iter_dropped(struct ring_buffer_iter *iter); > > > > > > unsigned long ring_buffer_size(struct trace_buffer *buffer, int cpu); > > > +unsigned long ring_buffer_memory_size(struct trace_buffer *buffer, int > > > cpu); > > > unsigned long ring_buffer_max_event_size(struct trace_buffer *buffer); > > > > > > void ring_buffer_reset_cpu(struct trace_buffer *buffer, int cpu); > > > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c > > > index 04bb94c29f58..efb88bf8970c 100644 > > > --- a/kernel/trace/ring_buffer.c > > > +++ b/kernel/trace/ring_buffer.c > > > @@ -6559,6 +6559,47 @@ unsigned long ring_buffer_size(struct trace_buffer > > > *buffer, int cpu) > > > } > > > EXPORT_SYMBOL_GPL(ring_buffer_size); > > > > > > +/** > > > + * ring_buffer_memory_size - return the memory used by the buffer (in > > > bytes) > > > + * @buffer: The ring buffer. > > > + * @cpu: The CPU to get ring buffer memory from. > > > + * > > > + * Returns the page-allocator memory consumed by @cpu, including the data > > > + * sub-buffers, the reader page, the cached read page, and the mmap > > > + * metadata page. Unlike ring_buffer_size(), which reports the usable > > > data > > > + * capacity, this accounts for the full pages allocated to the buffer. > > > + * Remote buffers do not own page-allocator memory and report zero. > > > + */ > > > +unsigned long ring_buffer_memory_size(struct trace_buffer *buffer, int > > > cpu) > > > +{ > > > + struct ring_buffer_per_cpu *cpu_buffer; > > > + unsigned long subbuf_size; > > > + unsigned long size; > > > + > > > + if (!cpumask_test_cpu(cpu, buffer->cpumask)) > > > + return 0; > > > + > > > + /* Remote buffers use externally owned memory. */ > > > + if (buffer->remote) > > > + return 0; > > For the persistent ring buffer, you also need to check > `buffer->range_addr_start`. > That is a reserved memory, which is outside of page allocator. > > > > > This is a generic interface. If you want to call this function on a remote > > buffer, you should be able to. > > But as the comment said, this function returns the size of page-allocator > memory. Is remote ring buffer allocated from host?
It is down to the trace_remote implementer where the memory comes from, but right now, all remote ring buffer are allocated from the buddy allocator. Although, even coming from a carveout, the low-level function should probably return something in any case, as it has all the informations it needs and to stay as generic as possible. Then, the caller (trace_stat) should know if the information is relevant or not, or where to account for it. (probably with TRACE_ARRAY_FL_ flags ?). trace_stat shouldn't report only what's relevant for Android. It can however split the report between persistent ring-buffers and the others. Overall, we could have cat trace_mem main: instances: snapshots: persistents: remotes: total_system: total_carveout: Which I believe would be a more accurate picture: First the memory sorted by "type" of buffers and then by "type of memory". > > > > > Moreover, remote buffer in-production current use is for Android... So not > > only > > ring_buffer_memory_size() should support them, but they should probably be > > actively reported somewhere... > > Maybe we should have different size accounting interface for remote buffer > and persistent buffer. For the remote, it should probably sit in trace_remote.c, which can call ring_buffer_memory_size(). trace_stat can then query the memory size from trace_remote. And actually I have a pending series where I keep the list of trace_remote [1] which would be a prerequisite. [1] https://lore.kernel.org/all/[email protected]/ > > Thanks, > > -- > Masami Hiramatsu (Google) <[email protected]> -- Vincent
