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 27547C83F1A for ; Fri, 11 Jul 2025 18:14:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5BBF6B009D; Fri, 11 Jul 2025 14:14:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A0C616B00A3; Fri, 11 Jul 2025 14:14:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8FB7C6B00A4; Fri, 11 Jul 2025 14:14:39 -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 7F8FA6B009D for ; Fri, 11 Jul 2025 14:14:39 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id BAB9912B587 for ; Fri, 11 Jul 2025 18:14:38 +0000 (UTC) X-FDA: 83652784236.10.214686A Received: from out-180.mta0.migadu.com (out-180.mta0.migadu.com [91.218.175.180]) by imf26.hostedemail.com (Postfix) with ESMTP id D9469140005 for ; Fri, 11 Jul 2025 18:14:36 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=NujaHfFY; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf26.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.180 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752257677; a=rsa-sha256; cv=none; b=V9Qa+EfeDDHA18RYuLtx3vpajpOJPX5l/tceFL7xf7+bUmj/nlAvJr3SBBL3xABQXnvCPv abWLtIQj6/t2s/mX2sC3BlZicQlBGgPepg1InZ3ths0j4IDXV0h2NJNvvbVDlTw+RqWHBD /S+NILRc9L1ylLKMWP+t27TR82T2H3U= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=NujaHfFY; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf26.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.180 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752257677; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DEDLNqYLAzAlmkyVAoBTURn15UXkdV8M1Di7IsBI+zg=; b=qUvw6TlciYhHdcwlaz/WkhZqe/u125aAT2WDAoIdPpJCVfYyk/KopqlUaC88zLl2pyf9x9 ohBztL3sWAbON6cpx/JCufZhO2nvtMZ9mYxJ7VwQB6C+pOk/EXHjVYH/pu/8XJQXiF1kEx 8faAv33QTf8Je9S7VdkQ8Rp6+Y2+JTg= Date: Fri, 11 Jul 2025 14:14:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1752257674; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DEDLNqYLAzAlmkyVAoBTURn15UXkdV8M1Di7IsBI+zg=; b=NujaHfFYo0+u2MQWXyCxgNDWyZEQzRpRDaGHmuShj8iN7cqW9CmGuqBJYGE2lDLvB4BNWO sV8UY+/9vBKiIw/fiUNXWKuIUUyRzTsPO0IN54+c9VZnV7wFq8+cmT7uMGlZ9J/Myfi34e KNgWSf8DDE36b+aWjBSrcDbw0tYMkLU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Casey Chen Cc: akpm@linux-foundation.org, surenb@google.com, corbet@lwn.net, dennis@kernel.org, tj@kernel.org, cl@gentwo.org, vbabka@suse.cz, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, rientjes@google.com, roman.gushchin@linux.dev, harry.yoo@oracle.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, yzhong@purestorage.com, souravpanda@google.com, 00107082@163.com Subject: Re: [PATCH v3] alloc_tag: add per-NUMA node stats Message-ID: References: <20250711002322.1303421-1-cachen@purestorage.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 1wm76xurxtuyi8nku6mxnkcmuzqhgmu7 X-Rspamd-Queue-Id: D9469140005 X-HE-Tag: 1752257676-370331 X-HE-Meta: U2FsdGVkX1/Xz+yjRGKA11Cy7T50rjHVocK4pXI9Uw3qmj8Gwy6weoVnsy9XDfJSULJGyBIZrtEpK64x2T1wm81SapgFs//Wp3BQ6px7h9JoW40j3w71bBRk4B9uUesAUI0cerrqtnA/d2269HJYhJdoO6jzZYexShd8WlWPSp7mw3kCs+Fdy9Wz6qn9hzCAM4L2nwsauLYIQYYxlNO7SVF74dePPE2jM+IJK1qO8zKWuF+C4vyWUmQ6/v3LcyDnQCyGcLKwNqPwLgIxkNoi6EKmW3FIU4CJQwS8SMbyBGjT8rm2VL5yZivA45oe8raSGfuHAEi3W2KTOh1Q4A07pCWrn4Tz0uOQ14G2io8RPpgFTFKIVB13OeU+qrhQmUoYQsYOHCqMLMVhqixPcdPzoikJ5Epq4hDdbjEnR8McsZLnYYqW0J8TKOMviCK2LA5qrsyiHG1veP84rPEpgz9JC3KJXAolbTEatFwHdyaP5qUhd2TCWaO24ZBdVSvP4gHtPCp5nYmuVwLQmzpceSw4qXr0ksAxAo7rDFRtmpz9rzitshzrOROi1l8+8cifTxDPEuGJfARpkcV0sn2cXxsZ3DpzDYm3VNUH0JuxXlwljr6C/CGQTT85eQXO8/3I0BZ71fh39upjbMXFOPWn9vXoIzjH58mdkMANQSzJa866FfMy/bjAcxoerOXzR2GKI3tc+q9UEu3VG00aLvl6OBklcDLcXCrzRTHxpC7SRTGNO69mzlYY5p/mboMINja/2Z2lhV/JJAAyyFP6V5hq9vuW31l/soxJ2wXQuJtNwt9wBqTDwAk6CG1uwNQ2P5YnQz7XufywBrJyG77uxTnpv8ff6OtIZK4mjCAkFvqerA1F1b/u1a4AvWejLJxFzzjIRGe7IgV/oulPWgSHxYo8m5MwAcB10W+6LCLGlS0eGMCZizqtZRHOB5xE6fKiYIWWrvgnSkZcpQYdlz55MM7vDpn CqpUQlIF ogtfYzensFHvE3D1Aw3Y2+x6PjDvNfVvE4d0iGcmfgeiCGZP+ukBEhXdj/XGdfNkSE2zW590eAuGOXoSH/OWPV1zB4KW6mafVGRNxKQRhQbOUme5xsYnakkAvQWp+qav5G4Zna4KZOBHYOyEbN7hV2BcTNMwkXWltG5aOSJyU3hlCzFiARP+Je076eneSorINKkYgdlGCZFPSy1B2y6qNmTmThx3jr2CxNpJSMwePHE1uIeUPjLiU0HEBYXQ10rp2onndAY068mg34MuZPr06wA/KbbuIjVUl5m/iMgJuB4uOnFSvkkHHxd9HwynqhJyDEk+ntr2rSAP74XkydFkBCKiWAQ== 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 Fri, Jul 11, 2025 at 10:41:36AM -0700, Casey Chen wrote: > On Thu, Jul 10, 2025 at 8:09 PM Kent Overstreet > wrote: > > > > On Thu, Jul 10, 2025 at 06:07:13PM -0700, Casey Chen wrote: > > > On Thu, Jul 10, 2025 at 5:54 PM Kent Overstreet > > > wrote: > > > > > > > > On Thu, Jul 10, 2025 at 05:42:05PM -0700, Casey Chen wrote: > > > > > Hi All, > > > > > > > > > > Thanks for reviewing my previous patches. I am replying some comments > > > > > in our previous discussion > > > > > https://lore.kernel.org/all/CAJuCfpHhSUhxer-6MP3503w6520YLfgBTGp7Q9Qm9kgN4TNsfw@mail.gmail.com/T/#u > > > > > > > > > > Most people care about the motivations and usages of this feature. > > > > > Internally, we used to have systems having asymmetric memory to NUMA > > > > > nodes. Node 0 uses a lot of memory but node 1 is pretty empty. > > > > > Requests to allocate memory on node 0 always fail. With this patch, we > > > > > can find the imbalance and optimize the memory usage. Also, David > > > > > Rientjes and Sourav Panda provide their scenarios in which this patch > > > > > would be very useful. It is easy to turn on an off so I think it is > > > > > nice to have, enabling more scenarios in the future. > > > > > > > > > > Andrew / Kent, > > > > > * I agree with Kent on using for_each_possible_cpu rather than > > > > > for_each_online_cpu, considering CPU online/offline. > > > > > * When failing to allocate counters for in-kernel alloc_tag, panic() > > > > > is better than WARN(), eventually the kernel would panic at invalid > > > > > memory access. > > > > > * percpu stats would bloat data structures quite a bit. > > > > > > > > > > David Wang, > > > > > I don't really understand what is 'granularity of calling sites'. If > > > > > NUMA imbalance is found, the calling site could request memory > > > > > allocation from different nodes. Other factors can affect NUMA > > > > > balance, those information can be implemented in a different patch. > > > > > > > > Let's get this functionality in. > > > > > > > > We've already got userspace parsing and consuming /proc/allocinfo, so we > > > > just need to do it without changing that format. > > > > > > You mean keep the format without per-NUMA info the same as before ? > > > My patch v3 changed the header and the alignment of bytes and calls. I > > > can restore them back. > > > > I mean an ioctl interface - so we can have a userspace program with > > different switches for getting different types of output. > > > > Otherwise the existing programs people have already written for > > consuming /proc/allocinfo are going to break. > > What does this IOCTL interface do ? get bytes/calls per allocating > site ? or get total bytes/calls per module ? or per-NUMA bytes/calls > for each allocating site or module ? > Would it be too much work for this patch ? If you can show me an > example, it would be useful. I can try implementing it. Since we're adding optional features the ioctl needs to pass in a flags argument for which features we want - per numa node stats for now, but I suspect more will come up (maybe we'll want to revisit number of calls per callsite). Return -EINVAL if we ask for something the running kernel doesn't support...