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 7E1D9C83F03 for ; Sun, 6 Jul 2025 15:21:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1AD328D0003; Sun, 6 Jul 2025 11:21:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 136FC8D0002; Sun, 6 Jul 2025 11:21:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 025868D0003; Sun, 6 Jul 2025 11:21:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id DDAC58D0002 for ; Sun, 6 Jul 2025 11:21:57 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 7303C109ADA for ; Sun, 6 Jul 2025 15:21:57 +0000 (UTC) X-FDA: 83634205074.17.9B2AF59 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) by imf13.hostedemail.com (Postfix) with ESMTP id A04DE20014 for ; Sun, 6 Jul 2025 15:21:55 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ftkek5vt; spf=pass (imf13.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.174 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751815315; 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=IQ6VtDJzg0rA9Fdv8HNN7WSpxObMdw5IrFRoduJekjU=; b=QeKU5fXA2lCB70dAQEVFih/dWj4TdzMWgPwxY8Wxp6j1mPVe8iqY18vyjecyFTWE6sxkhL PrY/shSG7i4YHv88fLOFELoskiRmqnWcmy0Qhq74LcA7keyO+Hkpog+CcOKwWSoEUAoZDd hhQ/5ubr/Il8cVSeeO5t8slM1NUaMH4= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ftkek5vt; spf=pass (imf13.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.174 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751815315; a=rsa-sha256; cv=none; b=Quc42AhcoHJG8YFVOnDNbVMzRr8GW9xpF/FyOkORr+gh/33AQP+lEdCHBC3SyBtMKlNZll w68GXB+tRxDeUCBQoH7w8Cq92I3pOZtX0l7llNGhs2ra1WGMEmsSUhyKb1WN1Lt5EJvmqJ zM4YKr1OBmD6jfrYrH8iL+QozbzBrLs= Date: Sun, 6 Jul 2025 11:21:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1751815313; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=IQ6VtDJzg0rA9Fdv8HNN7WSpxObMdw5IrFRoduJekjU=; b=ftkek5vt3i0VqkXq/0lx162ptt/8V39eQ7cp49tZojD1R4aRLevS0bETlgZOgXdcmrFPPE 8VKZv7VdjMzKx5mwh5bkrTnjU7gQBOcO0tAs8x6nQDYHXECxq5wMNQvUUqI5KHCAr/Q3YH qLiPpd6yLMZ9SRV/9sv0lEVG4dmEOkE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Li Zetao Cc: Peter Zijlstra , Ingo Molnar , Steven Rostedt , akpm@linux-foundation.org, surenb@google.com, linux-mm@kvack.org Subject: Re: [PATCH mm-next] alloc_tag: add total bytes allocation information Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: A04DE20014 X-Rspamd-Server: rspam09 X-Stat-Signature: fw3aauaw3i5utsyn7hfuxbxe8jcsgpmk X-HE-Tag: 1751815315-567125 X-HE-Meta: U2FsdGVkX18LLzRsWY98jxSEEwBVSs+ydedgkWpXW1NXX+h+y+//wDVdGx1NctA8Zi9rrIWyODGb4poQNTDEw2SFoB56TaDl5DWI/KXCywunpKDTKNS0vkXqLlNUH42+CjgdqiBBrTFIw4fSOogE5BNZqkSkMvBzpnV/HNZK9207zbQLfSX9YwPn/qDd0l8apMA18ze1M7F7osaEa2dLkgoSs2LL6AdCD3y3a9aqkkPILzlINUZYFmhenMCPcZPL4KftLL8sUP31ZlSN+kv+TDsg3DNfJr19SXKBb2pi0ZpzF3Q34DNR/oKxicx8XbATLX1VAzey44FkY6zk7FaHiQdVYHAZ4TKlUNef/xS88LpHRB16XBgIvSJAyhCWqMtpOWc1I197E75Gi1CE9sOsbGaDy4wxv+jxU6nC3O+iL8UX+OCaHsktQ893NMtSQJGQxO2BIcpqigg8a2nARcC3eXNJK9zwdi74jCYWqUQf5NdG1EHPYJruvmY8mBO9zZBUAsA29owreD0eP0R/g3tIeLkMfKvC5jIUkVCWoJUZ6sdJblQ//7DR7TxWfIn21JlATrNWtT7prkNUDsP+DmbvZ7NDZ30X7KQ2Q4E6QY57DbRxWAHqPSrB54wKOvhlk3pAA7MG3teLZ80L1nJit39F8GHy4s+1uxiXi6ZIC5uyDSIiIFPPhHp8iIvp76ynm8buuSH4wcYa5CuorCSkKufAh4BujpB8FcBxbwJDc7LGK83gAc2N+weAc2tdwrqV1KPEJ50iE9Fx1tFZT7MoFEmDmPwC2zP7NnTkOuqbF0Cxm4ibf3Twi2PWE2En9Wobq2Ce5fwKOjvtX6oad36jW6VvE16PSpoc5wPhfQp/oEWlGm4KuZftju228Q1mYX78idgFHNX3aJFCZHoSofXJtJyT6DXzD0izXtQ18HsD84JRhO9rBuxgk/iZI/7aHrHzftsAoZHmmvznYhq2gkT8qLl WEM9b30B +Zrboz7gMKmHQCAgf0mqHppQXsbAteeeox+O/p89++D07e35wd2qR0SUgZUY0ZjXe/98Q9sPkdSpsJicsbSTA40DXLTVATolMJvCdWoIi9gZHvGJ/NOD5svyxUVmhDyuNY3Pp4jtk+Ju4IMT0n6c5ZIQOBcED/ezyWK34LL59G0qipenBdsntgGOvhuocCgSYMvHW/5hx/P0CncGCQSIM7awCWM2b2pvT3TDpyO3OJ1aoSNGIUDZZbGorG+gdbPhPbV7ga9YswY8uI4n6fd9h7ubquAytfBta/9DAOItJjS/+VIypeFOsm3T3aW689fSn1E+M9S6ixMPExsnbMc2uyx89RkDKG16rX+69 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: On Sun, Jul 06, 2025 at 02:01:41PM +0800, Li Zetao wrote: > 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? We definitely don't want to dump more stuff in /proc, no. There have been multiple proposals that would dump more stuff in /proc/allocinfo, and we can't realistically do all that with a text interface - that needs to stay stable and simple. A userspace program reading data out via an ioctl will solve all the things people have been wanting: - Someone has been reading data out at high frequency for logging pretty graphs: we want to avoid string serialization/deserialization - An ioctl is easier to make extensible (unless we want to go json, but I'm not sure the kernel is ready for that...) - and that gives us a place to add commandline switches and arguments for displaying the data different ways (like the top command). I don't have time to implement it myself, but I can guide someone and do code review.