Re: [PATCH v4 1/2] tracing: add ring-buffer memory usage statistics in tracefs

On Thu, Sep 24, 2026 at 10:27:55AM +0900, Masami Hiramatsu wrote:

On Tue, 22 Sep 2026 10:41:30 +0100
Vincent Donnefort [off-list ref] wrote:

quoted

On Mon, Sep 21, 2026 at 07:30:45PM +0800, Xiang Gao wrote:

quoted

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.

quoted

quoted

Signed-off-by: Xiang Gao <redacted>
---
 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.

quoted

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".

 

quoted

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/20260817135517.3919534-2-vdonnefort@google.com/ (local)

Thanks,

-- 
Masami Hiramatsu (Google) [off-list ref]

-- 
Vincent