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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

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