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

[Steven Rostedt <rostedt@goodmis.org>]

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