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

Hi, Steve.


One accounting detail I would like to clarify before implementing this:
should buffers_mem and snapshot_buffers_mem include all memory owned by
the buffers, including slab-allocated ring-buffer metadata and reader
pages, or only the full pages backing the ring-buffer data?


My original lost-RAM use case primarily needs the non-slab page memory,
since slab is already accounted for separately. But I understand
"buffers_mem" and "total memory" may be intended to include both page
and slab allocations.


Thanks,
Xiang



________________________________
发件人: 高翔
发送时间: 2026年8月13日 20:47:44
收件人: Steven Rostedt
抄送: Xiang Gao; Masami Hiramatsu; Mathieu Desnoyers; Lorenzo Stoakes; gao xu; 印闯; [email protected]; [email protected]; [email protected]
主题: 答复: [External Mail]Re: [RFC] tracing: aggregate ring-buffer usage statistics


Thanks, Steve.

Understood.

I will add:

  /sys/kernel/tracing/trace_stats/total_memory_kb

The file will report:

  total:
  buffers_mem:
  snapshot_buffers_mem:

The values will cover the main and snapshot buffers of the global trace
array and all tracing instances across all tracing CPUs.

For the per-CPU view, I will follow the existing tracefs layout and add:

  /sys/kernel/tracing/trace_stats/per_cpu/cpuN/total_memory_kb

Each per-CPU file will report only the corresponding CPU's buffers
across the global trace array and all tracing instances.

Thanks,
Xiang



________________________________
发件人: Steven Rostedt <[email protected]>
发送时间: 2026年8月12日 23:47:04
收件人: 高翔
抄送: Xiang Gao; Masami Hiramatsu; Mathieu Desnoyers; Lorenzo Stoakes; gao xu; 印闯; [email protected]; [email protected]; [email protected]
主题: Re: [External Mail]Re: [RFC] tracing: aggregate ring-buffer usage statistics

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

On Wed, 12 Aug 2026 13:21:29 +0000
高翔 <[email protected]> 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