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