From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 287D2C83F05 for ; Sun, 6 Jul 2025 06:02:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B771E6B8075; Sun, 6 Jul 2025 02:02:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B28056B8067; Sun, 6 Jul 2025 02:02:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3DB16B8075; Sun, 6 Jul 2025 02:02:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8F5886B8067 for ; Sun, 6 Jul 2025 02:02:02 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 14B03C2973 for ; Sun, 6 Jul 2025 06:02:02 +0000 (UTC) X-FDA: 83632794084.13.098E7C8 Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by imf21.hostedemail.com (Postfix) with ESMTP id 17DCE1C0009 for ; Sun, 6 Jul 2025 06:01:59 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=m49Fajan; spf=pass (imf21.hostedemail.com: domain of lizetao.kernel@gmail.com designates 209.85.215.178 as permitted sender) smtp.mailfrom=lizetao.kernel@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751781720; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=P44zKYw8GcBFGgXiQUsuMKdit9QCplnb029+MXrD6wA=; b=4nuDUarEqRTZwMp59wfBe9xJcDn5uDv8ZTZdoGnOhxOSZrj3nGXHykAOqjXWqc1P4XYikZ DqwtupMoxx4zUeEV0Tz2X55CQnPJXIWuVv6jQpLY12/VGK/nxmYcQ+6AI9aG91d1O7sL44 uZaBh/+X6or+arn0HygEchBmpEk0EDg= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=m49Fajan; spf=pass (imf21.hostedemail.com: domain of lizetao.kernel@gmail.com designates 209.85.215.178 as permitted sender) smtp.mailfrom=lizetao.kernel@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751781720; a=rsa-sha256; cv=none; b=Xz9uwUwmofsuV0b2u2typifHqFPlB4h367OcmC8OTW36B3pOp/GEwZzeyJCSzrEO3MDQ3h KQ/0nYudskrDNEYUsIPZ9Al4eTw9kx7Gsl4aN03JOHfenvXjNCEDOJRR4lCKthHlTK8r8Z WTG2LhCY82eVOCHYrr7EX44+Nkk0I0c= Received: by mail-pg1-f178.google.com with SMTP id 41be03b00d2f7-b34dde96cbfso92666a12.2 for ; Sat, 05 Jul 2025 23:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751781719; x=1752386519; darn=kvack.org; h=in-reply-to:from:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=P44zKYw8GcBFGgXiQUsuMKdit9QCplnb029+MXrD6wA=; b=m49FajanwDKxrI3vadpHjUk+lFiYEL4QkqAqQM1veIgk9edcNQFqTSn7wXRi1hYUu4 Q1XeyIoqQnzfeXk9FXhNGo2phJdcC0onB+3l4Gv5UGAjk1uWTkj8RGk2wfSBpHHB8QU5 yqGMFwmbwouoewUKAsMh4TZs1bPNgNABGsL9WZSGETiUO5qKCbVEoYemAZZnNLxq0yfr ZOpg9/wATnhYUkaxP7nezsUdivuIhVwVOIhNVjk7XwOgufyukdNaZEY4qlwFuN/ur+7Y 46LjQSecCGU9SGdOVoXYM5N5BR6L6FNrPLOMhJ8whuSRziwNuM5IVnctG9ch4iat+M76 161g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751781719; x=1752386519; h=in-reply-to:from:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=P44zKYw8GcBFGgXiQUsuMKdit9QCplnb029+MXrD6wA=; b=LsMZRXvntm9vEBWofGohSi8CBytb0R3v6SzSQm/IqmoeCdFJ9Zeqq0s7JB17LhmNll p9BdzFVMGRNgAbu6OlXuPy/9hK8zoogo8AvcnFeaDv6pCENtRPnLb/e6DhFcBz1T4X9C /vatXU9EPG5LmtcyTxD3cXIZ/33+tATm0Rd5oKWoZ97MlI8O9ocNEdfd+D3fbPHcHwBC wJqV+2iqi+ReAeHFxJ8JnYQBZVpLGmd9tKaw1d2tzro+onLSh6GnztCvyRCE8NC0q929 eiIS+za47c3OaeAfLx4YZ3133fye4FGjNLkY+ux4zvA1+6LenHoSMqMS1aQL9nKuHmmS zqGg== X-Forwarded-Encrypted: i=1; AJvYcCUYQWPH8UnLuKPRmSb01DchMKvWSOHDzLlqzZ1t7/1qFvp05uus20aUhNqRPbnosF+0BGT79sNjtg==@kvack.org X-Gm-Message-State: AOJu0YxKBIJ2/Qkw3uzuXnDGY5wyVVnvHEIjJwbEl59OIFFpzyXnfPbP 1PNrkvJaugTBHqAr7jcHUbJhh3jMktof2hODXokM47s9g9xvElxGReBN X-Gm-Gg: ASbGncu16gP9icqt3l0DRLxyEfSTbpN53sx++981Fv6yaNdICo8rp/emZ9tN9J7Cdtw R1k/LCWbdzcgOLY8uzeoqq9UCg6Qkr67DfYRIAcJZQe7c9hkV0tmRBQGa/SsL6p1bO6tnQ/QphA +ojkknVv+Za99PgV769A1kOvMH8Ca4KLBTOJCUKeFN/xlTzRNOW0SHMK4gu3yNdmRAhUyrgQR43 twTpFwG45y4vApjYCN2aS8Af/5gcWGxGJAQXFX2gaw9x6Tw03k8kuos0m2DllrJOdzgyEt5r6/o u0JpDNf3gXV57SdWQrao/VvljiIIGTD/k/RVysGhTW0kHNn9nABan9stkbOpFHKIph0EcYU9Ds9 EqNNRht9BpGk= X-Google-Smtp-Source: AGHT+IEBgDB/ti69I9/Ad80EYWv1J1mwM8gLzS2j3X9XKuYArBi/LnapHsWpqAu1Ca+a3rWRCvto2w== X-Received: by 2002:a05:6a00:63c8:b0:747:b043:41d4 with SMTP id d2e1a72fcca58-74ce87dc68amr2790388b3a.4.1751781718903; Sat, 05 Jul 2025 23:01:58 -0700 (PDT) Received: from [192.168.158.197] ([106.120.219.98]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-74ce2b05749sm5454215b3a.0.2025.07.05.23.01.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Jul 2025 23:01:58 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------Z1T08ByBgmeGpZSjTIKnNean" Message-ID: Date: Sun, 6 Jul 2025 14:01:41 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH mm-next] alloc_tag: add total bytes allocation information To: Kent Overstreet , Peter Zijlstra , Ingo Molnar , Steven Rostedt Cc: akpm@linux-foundation.org, surenb@google.com, linux-mm@kvack.org References: From: Li Zetao In-Reply-To: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 17DCE1C0009 X-Rspam-User: X-Stat-Signature: 3f3eq1d1ot7no64y9efnnyazyt3ytob4 X-HE-Tag: 1751781719-351562 X-HE-Meta: U2FsdGVkX19fwsk75e1c/XVPmbzNabpDM2an0SZo8idLydDddjaGFAZeHCd2g9jG8SU9rAW74XwgE06CqhuNHXDfcNhtJ41U1Kj/IShIATzTFEBqpiBGBdLbgRmpnaiBSfqOkn32pRKD4JLy3fHQyjQ6FzHidiD+fhSCL2Qnvg0cSlkL5r/AE0ZhJNE56EXchdDTvoDu2UbkDDjdgV7FLgcyf/sE37BAWq/FHrnUs/MVmwePZ8mWX/EpBgs/gA8SyOSgGnAQKCX9NhxmcuGRPqWTxXA3IesW+r984iiQerYlHeI+Xlhsi2rl6YfykAABRag77Q5Bt3UPWZG9pZDmA08O7dw3Hl/FoureGk89q8961NNc5QmaVwOrni0qjtQucHDIKo4laLo7p+LZ3oKiOpdoitF7fRFJ2lHYrPulLjkK2H0Yq2eWcdO2sP15RVnweLWsyuBb8S+NMEvL6rubXx2rcfoOdcVLoYGTTr4CnSTv31WH1bulKsrH8CH2kXm42yAumVx3RCRTzlKRBKk3Cl4itJU6NrGkzofdDQAmiWnLmgd+qb15iQybfvYxUN/DsqYw2ONUEjYrwXtztwnZ9tOMH69MhAhxnY+n9vaNzahykoj8oOEJHNxOV3Nif0gEA37H36gM4JIP/Mzk23BmdJWMyAY0b9lrAOfVqbDGq7eoasz70IReiAE6SuwL1pVk7XgNhYPJ0geuMkPz1BnYucFVC2ScQt5BF5/bWkHzgHfTZY8vyIi4ReMg6wpld7b5jSWZagiV4tdM0mAfHs0GovCULcoVmujfg/kwFHpWbeET9yzZfY8waAN2JzbDN37fY6nP+eJ/+nRRn4Hj/RS59ZUU4J4oX2BXDdHufNu9RgqsRDBUPB0JFF1VwATGSvxHAD8K9g5D5Pqqbm4VyeE1/qguBz06XFaAmYUR5uWISFHv5LyWraHFUN2wuGxlUAl4Tg+tj9AJjvinJHuit0T Hl0fnE4P ddU6s4w7x3NEyWF1rAbR2wpTZhwNilfLy+mkkBsOu28seA8UXOPGfW/aXYLimEASPaSQK1YnbnJPOiYpT5Dk7ndQ0Jm84yLX8FwanW7R47P6eZaQbgo3TOjzqx5DkoR1GHJ944h6mWJc6YWU3rTAHuT5E/UQdKVEFph/YBlwIkD4nbyBnWVuqHLbp1Kk++14sOMcKEinxx3V/OkFSF8b3Wt+rN5Us/QTcbWFvflayJojJHRRWjNJaCX38OrRFvLV3adGAxXn51OPwgZlpy4Wes4Mwh/BRIrY0XE7IL/outotO9LJ6sIgvZX6F1YYwL3FOiHeJS4IGeDIMZvSs4F0I+cWuuEPLcgHg+QOjzBIGiNk2f40rsIs8yBr1qBDWcX7YWPYbZW0hZ3pFJqoEM9PI4xVpAdeIJJRmSQYuKsKbUxekL+nYwVbK6TcCVPEno51sC76ZFOstGg9Xl7JLIzRoMDCwiHd9b+ss2Tub2YyCMfAF0qNIhRKOh8jc8c6TNZSM9GP32wL70WHFt7G6wOnCB2XO2iXSjXhwqpTSWGtPBid6naEHVUrC+GYSFcKSatARioP5q6H2eLoQ18UTGmZZOW1dO91/IuJrjLEJVeexiA3uL3/id50Zwup/l29LRdtAPfAbAk+nF0w11YNkNzg3VmNxc1NvXDhtIFV6A1kQ1/8erEU6iOKZpTLIvhpnqTDCZfM5 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------Z1T08ByBgmeGpZSjTIKnNean Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 >> 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 --------------Z1T08ByBgmeGpZSjTIKnNean Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

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

--------------Z1T08ByBgmeGpZSjTIKnNean--