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

[Suren Baghdasaryan <surenb@google.com>]

On Sun, Jul 6, 2025 at 8:21 AM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> 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

Sorry for the late reply.
I'm trying to understand why this math has to be done in the kernel.
Why the userspace parser of this file can't simply read the file,
calculate the total allocations size and report it? I don't see the
value of doing that in the kernel as any allocation size can change at
any time even while we are reading this file. So, if you are concerned
about correctness of the reported total, it won't be any more correct
even if you do this inside the kernel AFAICT.

> > > 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.