Re: [PATCH mm-next] alloc_tag: add total bytes allocation information

[Kent Overstreet <kent.overstreet@linux.dev>]

On Sun, Jul 06, 2025 at 02:01:41PM +0800, Li Zetao wrote:
> Hi,
> 
> On 2025/7/3 1:14, Kent Overstreet wrote:
> > +cc Peter, Ingo, Steven
> > 
> > On Wed, Jul 02, 2025 at 12:38:06AM +0800, LiZetao wrote:
> > >  From bb3537ee638ac80eebcfe9160961e36df8d3ee4c Mon Sep 17 00:00:00 2001
> > > From: Li Zetao<lizetao.kernel@gmail.com>
> > > Date: Tue, 1 Jul 2025 09:30:16 +0000
> > > Subject: [PATCH mm-next] alloc_tag: add total bytes allocation information
> > > 
> > > Some performance monitoring tools focus on real-time memory
> > > usage anddisplay the total amount of memory applied, which is
> > > convenient for analyzing the memory usage ratio.
> > > 
> > > Added total information in /proc/allocinfo to feedback the
> > > total amount of memory applied to the user. Example is as
> > > follows:
> > > 
> > > root:~# cat /proc/allocinfo|tail
> > >         98112      168 lib/radix-tree.c:338 func:__radix_tree_preload
> > >         12848       22 lib/radix-tree.c:276 func:radix_tree_node_alloc
> > >        300760      515 lib/radix-tree.c:253 func:radix_tree_node_alloc
> > >             0        0 lib/xarray.c:1214 func:xas_try_split
> > >             0        0 lib/xarray.c:1059 func:xas_split_alloc
> > >        208488      357 lib/xarray.c:378 func:xas_alloc
> > >             0        0 lib/xarray.c:344 func:__xas_nomem
> > >             0        0 lib/xarray.c:341 func:__xas_nomem
> > >             0        0 lib/xarray.c:309 func:xas_nomem
> > > total: 102208196
> > This makes it harder to process the output (numfmt chokes on lines it
> > don't understand, which makes the header a real problem).
> > 
> > Given this and the per-numa-node patchset, I am inclined towards adding
> > an ioctl interface and a userspace tool to do the processing.
> 
> In my opinion, using ioctl is not very convenient. What do you think if a
> file like
> 
> /proc/allocinfo_total can solve this problem?

We definitely don't want to dump more stuff in /proc, no.

There have been multiple proposals that would dump more stuff in
/proc/allocinfo, and we can't realistically do all that with a text
interface - that needs to stay stable and simple.

A userspace program reading data out via an ioctl will solve all the
things people have been wanting:

- Someone has been reading data out at high frequency for logging pretty
  graphs: we want to avoid string serialization/deserialization

- An ioctl is easier to make extensible (unless we want to go json, but
  I'm not sure the kernel is ready for that...)

- and that gives us a place to add commandline switches and arguments
  for displaying the data different ways (like the top command).

I don't have time to implement it myself, but I can guide someone and do
code review.