[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

答复: [External Mail]Re: [PATCH] tracing: report buffer memory in /proc/meminfo

[高翔]

[-- Attachment #1: Type: text/plain, Size: 2664 bytes --]

Thanks for the suggestion.


The original motivation is Android lost-RAM attribution. Ftrace
ring-buffer data pages are not represented as a separate memory
category, so userspace can count them as lost RAM.


The buffers can be spread across the global trace array, multiple
instances, and snapshot buffers. Userspace currently has to discover
and sum every instance, and snapshot capacity is not available through
the same per-instance total. On one Android device, the global buffer
and 24 instances accounted for 395,664 kB, so the missing attribution
was significant.


I agree that /proc/meminfo is not the right interface. I will rework
this as an RFC under tracefs, with the tracing memory usage broken down
by category.


Thanks.



________________________________
发件人: Steven Rostedt <rostedt@goodmis.org>
发送时间: 2026年8月10日 22:57:10
收件人: Lorenzo Stoakes (ARM)
抄送: David Hildenbrand (Arm); Xiang Gao; Andrew Morton; Masami Hiramatsu; Mathieu Desnoyers; liam@infradead.org; Vlastimil Babka; Mike Rapoport; Suren Baghdasaryan; Michal Hocko; linux-trace-kernel@vger.kernel.org; linux-mm@kvack.org; linux-fsdevel@vger.kernel.org; linux-kernel@vger.kernel.org; 高翔
主题: [External Mail]Re: [PATCH] tracing: report buffer memory in /proc/meminfo

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

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

[-- Attachment #2: Type: text/html, Size: 4003 bytes --]

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

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

[Steven Rostedt]

On Tue, 11 Aug 2026 08:34:13 +0100
"Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:


> > > 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.?

Well, it can be gigabytes. When you boot up, the ring buffer is set to the
minimal amount which is two pages per CPU. On a 4K page machine with 32
CPUs, that works out to be around 128K.

You can see the minimal size by looking at the buffer_size_kb:

 ~# cat /sys/kernel/tracing/buffer_size_kb 
 7 (expanded: 1408)

(it's 7K of data storage rounded down after subtracting the meta data per page:
  4096 - 16 = 4080; 4080 * 2 / 1024 = 7 )

Notice that "expanded: 1408"? That means when tracing starts (enabling an
event or function tracing) it will expand to 1408K of data storage.

That means on that same 32 CPU machine, if tracing is started, the buffers
will expand to 45M. That's without the user increasing the size of the ring
buffer (by writing a bigger number into that buffer_size_kb file).

Now I do know of some companies that make the per CPU ring buffer 1 GB
each. On a 128 CPU machine, that is 128G of memory used for the ring buffer.

> 
> 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.

I wonder if it would be useful to show the tracing buffer if it is over
some watermark. That is, if the ring buffer is more than 10% of the memory
in the system, perhaps it would be good to show that?

-- Steve