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
