Hi,
+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: 102208196This 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