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

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

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

Kernel text interfaces are only good when they're simple and unchanging.
We can keep /proc/allocinfo for the basic stuff (it's very nice for
discoverability), and then we could have a tool (maybe in perf) where
you guys can go completely crazy.

Peter, Ingo, want a new perf tool?

Also, memory allocation profiling has been active enough that I'm
wondering if we should either add a mailing list or move it to a less
active one - either perf or tracing, they're both way less busy than mm.

Probably perf, unless Steven is interested. But memory allocation
profiling is the new oddball thing and I dunno what direction we'll go
in more.