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 D0C95C83038 for ; Wed, 2 Jul 2025 17:14:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 61A636B00C1; Wed, 2 Jul 2025 13:14:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5CB3D6B00C2; Wed, 2 Jul 2025 13:14:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 508966B00C3; Wed, 2 Jul 2025 13:14:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3D2E86B00C1 for ; Wed, 2 Jul 2025 13:14:30 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C7FA91A0363 for ; Wed, 2 Jul 2025 17:14:29 +0000 (UTC) X-FDA: 83619973458.18.9420E24 Received: from out-179.mta1.migadu.com (out-179.mta1.migadu.com [95.215.58.179]) by imf04.hostedemail.com (Postfix) with ESMTP id EAB0740005 for ; Wed, 2 Jul 2025 17:14:27 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=nt5GhADf; spf=pass (imf04.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.179 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=1751476468; 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:dkim-signature; bh=WAuCB9XTtupQV55DzJEAs398zyHwc3vKbLPckskVvTY=; b=67NQEAoG1TDMbWrrqzqxZNct181G8vTBBEio4EYekQ/Dqg33kxyEYhQA6J1CwTzvFLZXre 4oV0Jgay0KF0kMFJAdOXu5n6GqrnMKeDivkeC8czJnBBcr7BCfrNJ8LtKuJYykczWlzB1R nT8ox1gTsjddHbNtBc1kl5fH1IkSf4g= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=nt5GhADf; spf=pass (imf04.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.179 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=1751476468; a=rsa-sha256; cv=none; b=kQifkDViNAUyTk64sww9pEtoWkyUwLaq8NDkjzuF22VM6nMPkADOIwVdrcm9jg9nEOwOT7 8kAIM4ofkFudUroaiU0qPE51IEsSVLILpEtfy5fBvnvqBR49wBzzlaBKPYIfxtbsunY4T0 G+jsgq+PaCzX1g7kdIuKbEx36wXBdZA= Date: Wed, 2 Jul 2025 13:14:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1751476465; 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; bh=WAuCB9XTtupQV55DzJEAs398zyHwc3vKbLPckskVvTY=; b=nt5GhADfpc6o+I0YHyZMcFOpzAxQCdYeLBJLACCEhSWbjg7AlkbZNOX4uJi8TULgKbOJfo mWZOFf4rPpoU+8LJOzhjRJ0jeeZ+Fqb5OjF15UExpRCdQTzCBH7NaxleeyAmpxbXoWtBxa E237sOM0fvN9BWUVnRO5mYlg+mTf+uM= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: LiZetao , Peter Zijlstra , Ingo Molnar , Steven Rostedt Cc: 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: 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-Server: rspam06 X-Rspamd-Queue-Id: EAB0740005 X-Stat-Signature: rohpw9u9n55cymgtzqkuqsybc3cheejz X-HE-Tag: 1751476467-867983 X-HE-Meta: U2FsdGVkX1+jGerlDpD0BuFDLvVEO1BeK9ZaRu6jAEOOZhPyYgrxBlnZvR7BrxG6F8NTLiWuSdc0ms8J5AwPKSqUtgIQOG37VfqSoZsMack60ena6G8HQ7yt/wGAyv1amYZa9+lHkJKUOFGQmv778eHNUEC9h8ttikRc6j5nMiWjCLcIGQklYS17DdGTBCmxeCnZ0eYTOwnWrnLR4Rh4UkaGDsHTKEXcX8i1Zfh7uJhibnjzB86DJivFAayobWNJkCkXpxrWfxUpzJYapTui8Fc49VNJChOVsgYAHZolw5kurXTpl2yDMDi+MINXsd2KomVqnzQurN2RhxBH9qwlVKon6BHBHHQQCmSC9tNLJVjGtw234At/2BfNrszIkozFhXQGlWo3UXCChtOBBzXKyl+QP168w2zngsw4ZvKsy7GANnaNvLoD9MuTRuuAkQvU8ibmQ9ZTesxyfmH6RmgE3yMGGRezBq4asuLT8jsRd9ASnEsUvZfzWVYISD+16zu2Zb0vX7Qwt8B45hOGSZuay4X9WJM+dbMfFWC0RIGJ9UHXYQx8dZEwoVYhICSpXn4SWuzoEm0tjQUVSyIc/dACFxugX3ox0Mj6xBMikcBw+xm4wyZxfLFjIuVqzTaSn7mXJLh5+hBl4MXuai1Mn7x/J5lCKzj6ybOcVsGVgdBb0sI6cAQYiMJPiTND1pBx6z/02wfNtUgGVQFvUahPUQmjxoy09SgWLBVIAOMhBOlVxCpxmwYX53I1Iau+BcULHsRqx93+6LuAzrVpUlMVttA1+4OxRDQpHJk/NotrszYFH5rS00CvLmHO6XwBp1cNHOdOR4HWNfiKVbrxlQ9ps/PbcDlm+llv0u6HxyXsicyKwVSJf7PJTVmlr9XyvOhg4DIScEiiK6d21X26knEXCcbngARRi95u3MKQlTRHya4mcxP31Xx2hWyiqeo0D/1wugo1ALdzJ8kziqE5n03AYoV uuNMtC9A X7yDg4KmqxrUjQaS8q8zDMn7C5/YIcGMqQVw6CI7rXFAW8FBWkH7dowQ5BNRlmfwCLzX1H3hk5DK0pdr/HST1oK0G/iSKo85Tn154PSYGPlB1gZiwAYzbjNewn5z4EQQ4cnKtfZbFv0bPRd2914s41Cu0Gb5cvI9w8ZSv9QFyr7c7z0wpT2pNuO1GjgVJEEQRBE3Y4seFQWNFUv+wNA9Hc3C/feHoNTXN/TpAsslwAFHB+99ZkWqmi+o+wiCyv0t6r9CJNZ91eg0oOMp8EtJdypegGJAIL/lW54sbhejgwuUJfRhJp9kGhbNOIetYKO1Uag6Ygkxd1xbTrh/JY7bT2EcFHYcSEmAwB18F 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: +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. 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.