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 5EB54C5AD49 for ; Tue, 3 Jun 2025 17:34:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CFD746B04D3; Tue, 3 Jun 2025 13:34:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CAE5C6B04D4; Tue, 3 Jun 2025 13:34:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC4566B04D5; Tue, 3 Jun 2025 13:34:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A367B6B04D3 for ; Tue, 3 Jun 2025 13:34:45 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 370BBBEB49 for ; Tue, 3 Jun 2025 17:34:45 +0000 (UTC) X-FDA: 83514789330.05.61C463C Received: from out-178.mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) by imf04.hostedemail.com (Postfix) with ESMTP id 678DF4000F for ; Tue, 3 Jun 2025 17:34:43 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=GLVGM3Sa; spf=pass (imf04.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.178 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=1748972083; 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=asCN2M63UoC/kppTDWeSAcye3XDJAJ3BvHrvv6bj4Y8=; b=Zn6RO2X1lkJEKiQNQjUFLOm7Ei96DfVhfjBWBtWlG/GrfeBVxeucypujXCuTv6O2h1aMvz EPXD5OhJzjlHKTaZBkDUg8CB+BSunDuv7UvpylZUKR8Pfxmyqrk1MqJSh5OjkhV2lXwKWl ijvW/RVr6JQ99qeh0sMlW8Y8HHgbKJw= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=GLVGM3Sa; spf=pass (imf04.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.178 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=1748972083; a=rsa-sha256; cv=none; b=NnK1jNg13GJhqbKfhJg937W9JXxI2hz+DUZhGhL+7WMod21+38rTXmrqhGBGxcXJ/BVmKd Tx9kz7PnubiBVZfgFR9tnsZLd7IPGgLu7QuuAEQNwL4Ix0CssB52N9yRkl0XFZnjuR2Xhr JQcNQbzVjDmktvj1eRKShZ8ZPGvULEE= Date: Tue, 3 Jun 2025 13:34:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1748972081; 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=asCN2M63UoC/kppTDWeSAcye3XDJAJ3BvHrvv6bj4Y8=; b=GLVGM3SaFkBAa76sgK3g0ri0NItIo83z8KKWSzBOKUC+sl4vhUH+a7D8Y4CCKjzBx70tJ4 SR2j8r7TMqpx6jl2BA//qdC03t9tw654QosDJKC89pipozahLeSqIXApsujZopFa7M3njK rEVE+ZdahPPwrGXFRRxCKo43iAkXNec= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Suren Baghdasaryan Cc: Casey Chen , linux-mm@kvack.org, yzhong@purestorage.com Subject: Re: [PATCH 0/1] alloc_tag: add per-numa node stats Message-ID: References: <20250530003944.2929392-1-cachen@purestorage.com> <5iiwnofmnx565g3xv3zdt35b7qkuwylzedkidnav72t24asswj@omjgyjnauulg> 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-Queue-Id: 678DF4000F X-Stat-Signature: kuhax664h1ri3b5cumbiur3rexanndcd X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1748972083-418983 X-HE-Meta: U2FsdGVkX1++u2zcPkYEPC0fYTiYR5Ko2C53JaDgCUW0bV98g330j2O2yA77L0i3A9g3QQaXIw2pudueHSPa1sW2hVDJN12T9sRjlJrCmdnlCt+eryvLol7jg6FdgoMcEnCr9Rs4dQtLv46sZLsYOp2KlhFYTJzT0Jec5P4q9kCycZDciOHNgKjwc4g8lwoSKAjb7Eyr1oma0zGH/Txw4pJp/GH0HPSj/O2BwyNfBDUvLhd5s39KDXh/qetlu7q2DoOHqzgjSKnM4NrY6AOPy3wn1ZRFvGPxWTDkZwkB56NQoBDGGz4LRNpFSqvkhIBXeATVX66yijd5DH6hlEJMOK5OZJ05A+a/Y26Q3veSmyPvpW1XKCXvb8mtHmTw3nq0BQ8zdzuRpEBiPTZDu0xLaNmRx8Mfg5trmSShru7BhwsWz6ncVrehAllgrlz72i/sRgFN1nSCINOl1JXsc5GcZLg0Ao8t9kdIEZIq/8PVuiwhBUi/ngqmmtZUFuRUrEHnyPvhbGJqFIwV9RC2UqTevqle3UMdowDJvNG8wYAD9MUsuD2u/K8rPUfnvgB3UpFojRalwEkJWzIlZBd3OccodyjSjOb6psuyiwIQUDLbkdx0nezRRJMEthGSuxukLISXWSlYJ6IeuNiQZxpSF6WzjtJggVvH0Ye/HsWNN5/eoh0xr2O7caP16quRdo2h8HS28lkHaRyeftQQmjUdR7T+UrYWbwh+Eal2gtMTK6UdYNkk8OCLKjWqHqt45A1rnnU8y8nuxHWjgdfAHZL3OV0mLRtsOtiPDJRWJsUcKDqyg5QegafapPDTv7icIRd93SMgRDtyewdRx+wW/lhOOwk9/UK1L9tOonSL6YCBWVLbrYP+NfEvt3k9ipxxjurhfnnDkvGmu6XwSErP3cR/IO8kEsviqk5dbxEi9LomLvYmfq6wXBHPuMqzBO4CNGTA0djRRc0BN3uigMMVtalgu3V VN1ZuHwR PEzhHtPzDahQj4mgdjPtHytYF40R/dUx9RdGzdQJkIPtCp351W/obCOgmVLsefwXDpRCkbnmOz0uuQByDyXXRur9AxJt+4LOA322MJton8enuVo70AMXOxCvjs91JymbVu09kxmbSl0OjAZ7YrfSWpMUXhuU+5yz/MEq5PEACH/SaQt1fn4Lrqb53DX/NOAax7DzuqIEzF9ngknX9CK3u0zNz9gQRHq4N0LqWd4u5TS8GKLdcLA8bSSrcb8TIPTccsEVSF5mJ18OxSs3aKPkLbyfVQgfNtv7L9lxCnLkHa9dr7Tv2sNIB1XSMfRcAf1Wcb2586pY0QtV61yzsccj8XLxTeKMLvUzDoYjKBtirJtWNmnscSN9eSw2OkG9Mh2GEGA4fDx8jFQVhtP4= 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 Tue, Jun 03, 2025 at 08:00:59AM -0700, Suren Baghdasaryan wrote: > On Mon, Jun 2, 2025 at 2:32 PM Suren Baghdasaryan wrote: > > > > On Mon, Jun 2, 2025 at 1:48 PM Casey Chen wrote: > > > > > > On Fri, May 30, 2025 at 5:05 PM Kent Overstreet > > > wrote: > > > > > > > > On Fri, May 30, 2025 at 02:45:57PM -0700, Casey Chen wrote: > > > > > On Thu, May 29, 2025 at 6:11 PM Kent Overstreet > > > > > wrote: > > > > > > > > > > > > On Thu, May 29, 2025 at 06:39:43PM -0600, Casey Chen wrote: > > > > > > > The patch is based 4aab42ee1e4e ("mm/zblock: make active_list rcu_list") > > > > > > > from branch mm-new of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm > > > > > > > > > > > > > > The patch adds per-NUMA alloc_tag stats. Bytes/calls in total and per-NUMA > > > > > > > nodes are displayed in a single row for each alloc_tag in /proc/allocinfo. > > > > > > > Also percpu allocation is marked and its stats is stored on NUMA node 0. > > > > > > > For example, the resulting file looks like below. > > > > > > > > > > > > > > percpu y total 8588 2147 numa0 8588 2147 numa1 0 0 kernel/irq/irqdesc.c:425 func:alloc_desc > > > > > > > percpu n total 447232 1747 numa0 269568 1053 numa1 177664 694 lib/maple_tree.c:165 func:mt_alloc_bulk > > > > > > > percpu n total 83200 325 numa0 30976 121 numa1 52224 204 lib/maple_tree.c:160 func:mt_alloc_one > > > > > > > ... > > > > > > > percpu n total 364800 5700 numa0 109440 1710 numa1 255360 3990 drivers/net/ethernet/mellanox/mlx5/core/cmd.c:1410 [mlx5_core] func:mlx5_alloc_cmd_msg > > > > > > > percpu n total 1249280 39040 numa0 374784 11712 numa1 874496 27328 drivers/net/ethernet/mellanox/mlx5/core/cmd.c:1376 [mlx5_core] func:alloc_cmd_box > > > > > > > > > > > > Err, what is 'percpu y/n'? > > > > > > > > > > > > > > > > Mark percpu allocation with 'percpu y/n' because for percpu allocation > > > > > stats, 'bytes' is per-cpu, we have to multiply it by the number of > > > > > CPUs to get the total bytes. Mark it so we know the exact amount of > > > > > memory used. Any /proc/allocinfo parser can understand it and make > > > > > correct calculations. > > > > > > > > Ok, just wanted to be sure it wasn't something else. Let's shorten that > > > > though, a single character should suffice (we already have a header that > > > > can explain what it is) - if you're growing the width we don't want to > > > > overflow. > > > > > > > > > > Does it have a header ? > > > > Yes. See print_allocinfo_header(). > > I was thinking if instead of changing /proc/allocinfo format to > contain both total and per-node information we can keep it as is > (containing only totals) while exposing per-node information inside > new /sys/devices/system/node/node/allocinfo files. That seems > cleaner to me. > > I'm also not a fan of "percpu y" tags as that requires the reader to > know how many CPUs were in the system to make the calculation (you > might get the allocinfo content from a system you have no access to > and no additional information). Maybe we can have "per-cpu bytes" and > "total bytes" columns instead? For per-cpu allocations these will be > different, for all other allocations these two columns will contain > the same number. Maybe we can just report a single byte count, and multiply it by the number of CPUs for percpu allocations? Do we really need to know if a given allocation is percpu that often?