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?

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

Indeed, I often have to check some allocation profiling related mails on the

linux-mm mailing list, which is tedious. Can you consider a separate 
mailing list,

but I am not sure about the development direction of allocation profiling.


---

Li Zetao