From: 高翔 <gaoxiang17@xiaomi.com>
To: Steven Rostedt <rostedt@goodmis.org>,
"Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: "David Hildenbrand (Arm)" <david@kernel.org>,
Xiang Gao <gxxa03070307@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
"liam@infradead.org" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
"linux-trace-kernel@vger.kernel.org"
<linux-trace-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: 答复: [External Mail]Re: [PATCH] tracing: report buffer memory in /proc/meminfo
Date: Tue, 11 Aug 2026 03:44:14 +0000 [thread overview]
Message-ID: <b1378a355ce648a7b994d1ec8d56f10d@xiaomi.com> (raw)
In-Reply-To: <20260810105710.6ee5e493@gandalf.local.home>
[-- 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 --]
next prev parent reply other threads:[~2026-08-11 3:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 9:40 [PATCH] tracing: report buffer memory in /proc/meminfo Xiang Gao
2026-08-10 10:52 ` David Hildenbrand (Arm)
2026-08-10 11:22 ` Lorenzo Stoakes (ARM)
2026-08-10 14:57 ` Steven Rostedt
2026-08-11 3:44 ` 高翔 [this message]
2026-08-11 6:22 ` gao xu
2026-08-11 7:34 ` Lorenzo Stoakes (ARM)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b1378a355ce648a7b994d1ec8d56f10d@xiaomi.com \
--to=gaoxiang17@xiaomi.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=gxxa03070307@gmail.com \
--cc=liam@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).