[RFC] tracing: aggregate ring-buffer usage statistics

[RFC] tracing: aggregate ring-buffer usage statistics

[Xiang Gao]

Hi,

I would like to clarify the motivation for a tracing-specific memory
usage interface.

The original requirement comes from Android lost-RAM attribution.
Ftrace ring-buffer data pages are not represented as a separate memory
category, so userspace memory diagnostics may treat them as lost RAM.

The memory can be spread across the global trace array, dynamically
created tracing instances, and snapshot buffers. Userspace can read
buffer_total_size_kb for the global trace array and each instance, but
it has to discover and sum all instances, and snapshot buffer capacity
is not exposed through the same per-instance total.

On one Android device, the global buffer and 24 tracing instances
accounted for 395,664 kB of ring-buffer data capacity. This makes the
missing attribution significant for low-memory diagnostics.

The core requirement is a stable tracing-specific interface that allows
userspace to obtain the aggregate tracing buffer usage without walking
all instances. It does not need to be part of /proc/meminfo or
show_mem().

One possible interface would be under:

  /sys/kernel/tracing/trace_stats/

It could provide an aggregate buffer value together with a breakdown
for main and snapshot buffers. Per-CPU statistics could also be added
if useful.

Thanks,
Xiang

Re: [RFC] tracing: aggregate ring-buffer usage statistics

[Steven Rostedt]

On Tue, 11 Aug 2026 19:48:18 +0800
Xiang Gao <gxxa03070307@gmail.com> wrote:

> One possible interface would be under:
> 
>   /sys/kernel/tracing/trace_stats/
> 
> It could provide an aggregate buffer value together with a breakdown
> for main and snapshot buffers. Per-CPU statistics could also be added
> if useful.

As I previous said. I'm OK with adding a file there.

-- Steve

Re: [External Mail]Re: [RFC] tracing: aggregate ring-buffer usage statistics

[Steven Rostedt]

On Wed, 12 Aug 2026 13:21:29 +0000
高翔 <gaoxiang17@xiaomi.com> wrote:

> Thanks, Steve.
> 
> For the initial implementation, I plan to add:
> 
>   /sys/kernel/tracing/trace_stats/total_memory_kb
> 
> The file would use an extensible key/value format. Initially it would
> report the ring-buffer data capacity:
> 
>   total:                   395664
>   ring_buffer:             395664
>   ring_buffer_live:        395544
>   ring_buffer_snapshot:       120

You can rename the above to:

   total:
   buffers_mem:
   snapshot_buffers_mem:

No need to use "ring" and it keeps consistent with "buffer_size_kb".

I added the "mem" part to distinguish the difference between these numbers
and the buffer_size_kb, as these numbers are about total memory whereas
the "buffer_size_kb" is about usable memory.

There's already a total for all memory listed. We don't need to have a
total for the "live" and "snapshot".

> 
> Here, ring_buffer is the sum of ring_buffer_live and
> ring_buffer_snapshot. The values cover the global trace array and all
> tracing instances across all tracing CPUs.
> 
> Additional accounted categories, such as event memory, could be appended
> later and included in total. Per-CPU statistics could be exposed
> separately under trace_stats/per_cpu/cpuN/ to avoid mixing aggregate and
> per-CPU values in one file.

Agreed, this file should exist in the cpuN/ directories and be only for
those instances.

> 
> Userspace would parse fields by name and ignore unknown fields, so new
> categories can be added without changing the existing format.

Right. I would expect additional items to be added here.

> 
> Does this initial format look reasonable?
> 

Yes, thanks for doing this.

-- Steve