[RFC] tracing: aggregate ring-buffer memory statistics

[RFC] tracing: aggregate ring-buffer memory statistics

[Xiang Gao]

Hi,

This is a resend of the RFC for exposing tracing buffer memory
statistics under tracefs.

The motivation is Android lost-RAM attribution: tracing buffer memory
is not represented as a separate category, so it can be counted as lost
RAM. The memory can be spread across the global trace array, dynamically
created instances, and snapshot buffers, and userspace currently has to
discover and sum every instance.

The patch adds:

  /sys/kernel/tracing/trace_stats/total_memory_kb

reporting:

  total:
  buffers_mem:
  snapshot_buffers_mem:

The values cover the global trace array and all instances across all
CPUs. A per-CPU view is provided under:

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

These *_mem values report the full pages backing the data sub-buffers
and reader page, unlike buffer_size_kb / buffer_total_size_kb which
report usable data capacity. The new trace_stats directory is distinct
from the existing trace_stat directory used for function and branch
counters.

For example, with 4 CPUs and 2 sub-buffers per CPU on a 4 KiB page
system:

  buffer_size_kb        = (4096 - 16) * 2 / 1024 = 7 kB     (one CPU)
  buffer_total_size_kb  = 7 * 4 = 28 kB                    (one array)
  buffers_mem           = (2 + 1) * 4096 * 4 / 1024 = 48 kB

The extra memory in buffers_mem comes from the per-page header and the
reader page.

Slab-allocated ring-buffer metadata is not included.

One open question is whether reporting page memory only is acceptable
for the initial version.

Thanks,
Xiang

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

[Steven Rostedt]

On Thu, 27 Aug 2026 14:25:24 +0000
高翔 <gaoxiang17@xiaomi.com> wrote:

> Hi Steven.
> 

It's good to ping after one week of no responses. RFCs tend to get low
priority and are looked at after fixes and other code needs to be reviewed.

But I'll take a look now anyway as I just finished sending out fixes.

-- Steve

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

[Steven Rostedt]

On Tue, 25 Aug 2026 22:10:15 +0800
Xiang Gao <gxxa03070307@gmail.com> wrote:

> Slab-allocated ring-buffer metadata is not included.
> 
> One open question is whether reporting page memory only is acceptable
> for the initial version.

As supposed to what? The meta-data? I think meta-data is also good to show,
if it is allocated. Maybe as a separate line item?

-- Steve

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

[Steven Rostedt]

On Wed, 2 Sep 2026 02:24:23 +0000
高翔 <gaoxiang17@xiaomi.com> wrote:

> Hi Steve,
> 
> 
> Just checking if the metadata split I proposed last time looks
> reasonable, so I know whether to proceed with the implementation:
> 
> 
>   total:
>   buffers_mem:
>   snapshot_buffers_mem:
>   metadata_mem:
> 
> 
> where buffers_mem and snapshot_buffers_mem report all page memory, and
> metadata_mem reports the slab-allocated ring-buffer metadata.
> 
> 
> Would you like me to proceed with this split?
> 

Let's start with just the buffers for now. Thinking about this more, the
file can be called "memory_usage" and we can drop the "_mem" part of the
items.

 # cat memory_usage_kb
 buffers: XXX
 snapshot buffers: XXX


We can then add more information later.

-- Steve

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

[Steven Rostedt]

On Wed, 2 Sep 2026 14:31:17 +0000
高翔 <gaoxiang17@xiaomi.com> wrote:

> The values are in KiB. Should I keep a separate total line, or will the
> two categories suffice for now?

Just the two lines. People can add for themselves ;-)

-- Steve

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

[Steven Rostedt]

On Wed, 2 Sep 2026 14:46:21 +0000
高翔 <gaoxiang17@xiaomi.com> wrote:

> Thanks, Steve.
> 
> 
> One more question on the per-CPU view. Should I also provide:
> 
>   /sys/kernel/tracing/trace_stats/per_cpu/cpuN/memory_usage_kb
> 
> 
> with the same two-line format, reporting only the buffers belonging to
> that CPU? Or should the initial version only have the top-level
> memory_usage_kb file?
> 
> Once this is settled, I'll send the patch for review.

You can add it as a separate patch in the series.

-- Steve