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

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

On Mon, Jul 07, 2025 at 07:05:18PM -0700, Suren Baghdasaryan wrote:
> 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.

exactly - hoping to nudge someone to write the userspace frontend :)