[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

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

[高翔]

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]


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

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.

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

Does this initial format look reasonable?

Thanks,
Xiang



________________________________
发件人: Steven Rostedt <rostedt@goodmis.org>
发送时间: 2026年8月11日 22:08:30
收件人: Xiang Gao
抄送: Masami Hiramatsu; Mathieu Desnoyers; Lorenzo Stoakes; gao xu; 印闯; linux-trace-kernel@vger.kernel.org; linux-kernel@vger.kernel.org; linux-mm@kvack.org; 高翔
主题: [External Mail]Re: [RFC] tracing: aggregate ring-buffer usage statistics

[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给misec@xiaomi.com进行反馈

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

[-- Attachment #2: Type: text/html, Size: 3508 bytes --]

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