[PATCH] tracing: report buffer memory in /proc/meminfo

[PATCH] tracing: report buffer memory in /proc/meminfo

[Xiang Gao]

Report the data capacity of all ftrace ring buffers through a new Ftrace
field in /proc/meminfo. Include the main and snapshot buffers of the
global trace array and all tracing instances, while leaving ring-buffer
metadata accounted for by Slab.

Keep the interface as a no-op when tracing is disabled so /proc/meminfo
does not gain a configuration dependency on tracing.

Tested on arm64 QEMU:

  CONFIG_TRACING=n:                   0 kB
  Global resize/restore:          7 -> 4099 -> 7 kB
  Instance and snapshot lifecycle: 15 -> 1434 -> 2836 -> 1434 -> 15 kB

Signed-off-by: Xiang Gao <gaoxiang17@xiaomi.com>
---
 fs/proc/meminfo.c     |  3 +++
 include/linux/trace.h |  5 +++++
 kernel/trace/trace.c  | 30 ++++++++++++++++++++++++++++++
 3 files changed, 38 insertions(+)

diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index b2813ff13cb2..96a38ffc4e35 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -18,6 +18,7 @@
 #include <linux/cma.h>
 #endif
 #include <linux/zswap.h>
+#include <linux/trace.h>
 #include <asm/page.h>
 #include "internal.h"
 
@@ -108,6 +109,8 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
 	show_val_kb(m, "Slab:           ", sreclaimable + sunreclaim);
 	show_val_kb(m, "SReclaimable:   ", sreclaimable);
 	show_val_kb(m, "SUnreclaim:     ", sunreclaim);
+	seq_printf(m, "Ftrace:         %8lu kB\n",
+		   ftrace_buffer_total_size() >> 10);
 	seq_printf(m, "KernelStack:    %8lu kB\n",
 		   global_node_page_state(NR_KERNEL_STACK_KB));
 #ifdef CONFIG_SHADOW_CALL_STACK
diff --git a/include/linux/trace.h b/include/linux/trace.h
index 7eaad857dee0..f9935231560c 100644
--- a/include/linux/trace.h
+++ b/include/linux/trace.h
@@ -53,6 +53,7 @@ int trace_array_init_printk(struct trace_array *tr);
 void trace_array_put(struct trace_array *tr);
 struct trace_array *trace_array_get_by_name(const char *name, const char *systems);
 int trace_array_destroy(struct trace_array *tr);
+unsigned long ftrace_buffer_total_size(void);
 
 /* For osnoise tracer */
 int osnoise_arch_register(void);
@@ -92,6 +93,10 @@ static inline int trace_array_destroy(struct trace_array *tr)
 {
 	return 0;
 }
+static inline unsigned long ftrace_buffer_total_size(void)
+{
+	return 0;
+}
 #endif	/* CONFIG_TRACING */
 
 #endif	/* _LINUX_TRACE_H */
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 01a5e87af299..f0bb553e3688 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -5769,6 +5769,36 @@ tracing_total_entries_read(struct file *filp, char __user *ubuf,
 	return simple_read_from_buffer(ubuf, cnt, ppos, buf, r);
 }
 
+static unsigned long trace_array_buffer_size(struct array_buffer *buf)
+{
+	unsigned long size = 0;
+	int cpu;
+
+	if (!buf->buffer)
+		return 0;
+
+	for_each_tracing_cpu(cpu)
+		size += ring_buffer_size(buf->buffer, cpu);
+
+	return size;
+}
+
+unsigned long ftrace_buffer_total_size(void)
+{
+	struct trace_array *tr;
+	unsigned long size = 0;
+
+	guard(mutex)(&trace_types_lock);
+	list_for_each_entry(tr, &ftrace_trace_arrays, list) {
+		size += trace_array_buffer_size(&tr->array_buffer);
+#ifdef CONFIG_TRACER_SNAPSHOT
+		size += trace_array_buffer_size(&tr->snapshot_buffer);
+#endif
+	}
+
+	return size;
+}
+
 #define LAST_BOOT_HEADER ((void *)1)
 
 static void *l_next(struct seq_file *m, void *v, loff_t *pos)
-- 
2.34.1

Re: [PATCH] tracing: report buffer memory in /proc/meminfo

[David Hildenbrand (Arm)]

On 8/10/26 11:40, Xiang Gao wrote:
> Report the data capacity of all ftrace ring buffers through a new Ftrace
> field in /proc/meminfo. Include the main and snapshot buffers of the
> global trace array and all tracing instances, while leaving ring-buffer
> metadata accounted for by Slab.

why? :)

To report a handful of KiB as in your example below? Doesn't sound super helpful
TBH.

-- 
Cheers,

David

Re: [PATCH] tracing: report buffer memory in /proc/meminfo

[Lorenzo Stoakes (ARM)]

On Mon, Aug 10, 2026 at 12:52:38PM +0200, David Hildenbrand (Arm) wrote:
> On 8/10/26 11:40, Xiang Gao wrote:
> > Report the data capacity of all ftrace ring buffers through a new Ftrace
> > field in /proc/meminfo. Include the main and snapshot buffers of the
> > global trace array and all tracing instances, while leaving ring-buffer
> > metadata accounted for by Slab.
>
> why? :)
>
> To report a handful of KiB as in your example below? Doesn't sound super helpful
> TBH.

Yeah I think we need to stop with all the proposed additions to /proc/meminfo :)

Also something like this where you are making a change in output that it is just
your opinion that it is useful should be an RFC to see what the community thinks
first.

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo

Re: [PATCH] tracing: report buffer memory in /proc/meminfo

[Steven Rostedt]

On Mon, 10 Aug 2026 12:22:43 +0100
"Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:

> On Mon, Aug 10, 2026 at 12:52:38PM +0200, David Hildenbrand (Arm) wrote:
> > On 8/10/26 11:40, Xiang Gao wrote:  
> > > Report the data capacity of all ftrace ring buffers through a new Ftrace
> > > field in /proc/meminfo. Include the main and snapshot buffers of the
> > > global trace array and all tracing instances, while leaving ring-buffer
> > > metadata accounted for by Slab.  
> >
> > why? :)
> >
> > To report a handful of KiB as in your example below? Doesn't sound super helpful
> > TBH.  
> 
> Yeah I think we need to stop with all the proposed additions to /proc/meminfo :)
> 
> Also something like this where you are making a change in output that it is just
> your opinion that it is useful should be an RFC to see what the community thinks
> first.

Agreed. This doesn't belong in the meminfo. If you want memory statistics
for tracing, I may be OK if you add a "total_memory_kb" file in the
/sys/kernel/tracing/trace_stats/ directory.

And break it up for memory used. Ring buffers, events, etc.

Perhaps even add one per CPU as well.

I'm always conscience about how much memory tracing is taking up in the
system.

-- Steve

RE: [PATCH] tracing: report buffer memory in /proc/meminfo

[gao xu]

> On Mon, 10 Aug 2026 12:22:43 +0100
> "Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:
> 
> > On Mon, Aug 10, 2026 at 12:52:38PM +0200, David Hildenbrand (Arm) wrote:
> > > On 8/10/26 11:40, Xiang Gao wrote:
> > > > Report the data capacity of all ftrace ring buffers through a new
> > > > Ftrace field in /proc/meminfo. Include the main and snapshot
> > > > buffers of the global trace array and all tracing instances, while
> > > > leaving ring-buffer metadata accounted for by Slab.
> > >
> > > why? :)
> > >
> > > To report a handful of KiB as in your example below? Doesn't sound
> > > super helpful TBH.
> >
> > Yeah I think we need to stop with all the proposed additions to
> > /proc/meminfo :)
> >
> > Also something like this where you are making a change in output that
> > it is just your opinion that it is useful should be an RFC to see what
> > the community thinks first.
> 
> Agreed. This doesn't belong in the meminfo. If you want memory statistics for
> tracing, I may be OK if you add a "total_memory_kb" file in the
> /sys/kernel/tracing/trace_stats/ directory.
Would it be possible to include this info in show_mem()?
This would be helpful for analyzing low-memory and OOM issues.
> 
> And break it up for memory used. Ring buffers, events, etc.
> 
> Perhaps even add one per CPU as well.
> 
> I'm always conscience about how much memory tracing is taking up in the
> system.
> 
> -- Steve

Re: [PATCH] tracing: report buffer memory in /proc/meminfo

[Lorenzo Stoakes (ARM)]

On Tue, Aug 11, 2026 at 06:22:58AM +0000, gao xu wrote:
> > On Mon, 10 Aug 2026 12:22:43 +0100
> > "Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:
> >
> > > On Mon, Aug 10, 2026 at 12:52:38PM +0200, David Hildenbrand (Arm) wrote:
> > > > On 8/10/26 11:40, Xiang Gao wrote:
> > > > > Report the data capacity of all ftrace ring buffers through a new
> > > > > Ftrace field in /proc/meminfo. Include the main and snapshot
> > > > > buffers of the global trace array and all tracing instances, while
> > > > > leaving ring-buffer metadata accounted for by Slab.
> > > >
> > > > why? :)
> > > >
> > > > To report a handful of KiB as in your example below? Doesn't sound
> > > > super helpful TBH.
> > >
> > > Yeah I think we need to stop with all the proposed additions to
> > > /proc/meminfo :)
> > >
> > > Also something like this where you are making a change in output that
> > > it is just your opinion that it is useful should be an RFC to see what
> > > the community thinks first.
> >
> > Agreed. This doesn't belong in the meminfo. If you want memory statistics for
> > tracing, I may be OK if you add a "total_memory_kb" file in the
> > /sys/kernel/tracing/trace_stats/ directory.
> Would it be possible to include this info in show_mem()?
> This would be helpful for analyzing low-memory and OOM issues.

You have to back up requests with reasons, it's not a case of 'please add X to
Y' and then we deign to do it or not.

Justifications are required. We could add endless crap to show_mem() until the
CoWs come home, maybe even list the number of emojis used since last boot
obviously.

So - why are you asking for this? Is it only a handful of KiB used for tracing?
Is it GiB? If so maybe it's because you're doing something crazy? Why does a
kernelfs file not suffice, etc.?

You need to engage with the discussion and back things up rather just asking
like you were typing into an LLM prompt...

But in general, no, it makes absolutely no sense to randomly output some trace
information there, unless you're about to offer up the most compelling argument
since the invention of marmite and butter on toast.

show_mem() is for critical memory information displayed at the point of OOM or
sysrq-please-help-me, not random stats.

> >
> > And break it up for memory used. Ring buffers, events, etc.
> >
> > Perhaps even add one per CPU as well.
> >
> > I'm always conscience about how much memory tracing is taking up in the
> > system.
> >
> > -- Steve
>

--
Cheers, Lorenzo