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

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