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