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 77257C83F1A for ; Thu, 10 Jul 2025 05:54:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E87A36B00A3; Thu, 10 Jul 2025 01:54:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E37BD6B00A6; Thu, 10 Jul 2025 01:54:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D264F6B00A9; Thu, 10 Jul 2025 01:54:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BBE196B00A3 for ; Thu, 10 Jul 2025 01:54:15 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6AA721406C7 for ; Thu, 10 Jul 2025 05:54:15 +0000 (UTC) X-FDA: 83647289670.29.15922D1 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf01.hostedemail.com (Postfix) with ESMTP id B872340013 for ; Thu, 10 Jul 2025 05:54:13 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fmdg35wj; spf=pass (imf01.hostedemail.com: domain of souravpanda@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=souravpanda@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752126853; 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=HelAxtimgRzObN608eoZdcv1cFYYfoEA/RL9Fs/79Nc=; b=5QqKZC3Om8VhTbN5MgVjE7rSZF3RDJPcAew+HMx20Gz+JgAE7QlgRehB9HApjeExdUF7mb yVP4nOoguOanqn6wv7umnvn9YlOw615U5sX/X9lEOjF5ipcZb+tIeJ5qUWKGV98qvMpnH8 m7GENcG9Ptv9qDSgXP5q383jFYvlsp4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fmdg35wj; spf=pass (imf01.hostedemail.com: domain of souravpanda@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=souravpanda@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752126853; a=rsa-sha256; cv=none; b=XDoaZna/yV8AGHSkqmL1JwR1Yydfy/DgjdmXW4eeIWW0sB5sCNHb7V6QjL3NsvLuCJx7Px IDjOn7IcIOmoKUbCvQfI0tnp00yQjdpaF8kn/SErkfPcODnnG8n078XeNQ6G/3PZyXgMK6 3fOzKeKINKrTxQjHeQV/y4Q463ltGrQ= Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-4a7fc24ed5cso151041cf.1 for ; Wed, 09 Jul 2025 22:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752126853; x=1752731653; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HelAxtimgRzObN608eoZdcv1cFYYfoEA/RL9Fs/79Nc=; b=fmdg35wj5W160/KqYuddPi/PUaP9yE24Kfx20T1ifsYStej406mnJ+hcWQZA+sLMeH /FW5etUM2CCzRylBLB9VVhy5h6MFPrSpGsZvebSRPdEAH1CzSFbafkCVbDppv0vSszOU j/63LUvX9DYjLNrFASzw95DhwMPipLv5OHHsERNZPUzVvKNw6YjiUGs3tCSmb7qOnlzl WFCe0e/AImWFrkCzEAaOIagjvFtykJ70xruv5NYRxbxM+PNasu0UBri7RoT2A456nFau k0j37SwgUySqC+7QK1UCiV3udU/dJqTGHS2APWSOMvSYoqVbCuRpSt7yfLEFD0SY05FJ Yf9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752126853; x=1752731653; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HelAxtimgRzObN608eoZdcv1cFYYfoEA/RL9Fs/79Nc=; b=Ai3Jg5oVOT0DXznVLE3Wu/Tzu5p8OD4Cv2WJNEtMVOzqO6/EhbqM4wD+LU5MNmaQTE 01Vq06LOErqG5N1JOPA4S0ZNizhPUdFnZJnp3/hpunwmT+chnjiUbzySN+nzRthqGuYz LDytfNS5k9uTgsl7umvEKTJGQiQiJdBQBgBZU920HGta8HFxS84y2u1lxyZm2GQWUR8G w62EaziZWmOof8oU6r0wKs/Zo9slwn6ZIhbzdSogThzhfPesMA78QwDqgEqsrW+apuhZ I2JTSYf9s+nBZRUK+uArrWEX21Pb1NbOOVfvKQXaMqibkZei62gsIRVhtClhbc/ya+8r B1Dg== X-Forwarded-Encrypted: i=1; AJvYcCU8eiyzAV/KgxmwCAoSQ6t2RaeNOnMkh8h2OSQDB5K6dfUz991A2TUFqZX4HRzIJvvaO5UZzd7R4Q==@kvack.org X-Gm-Message-State: AOJu0YyC+RUb7IqbsTAN5u9XUcdjmm4ACw4H3Z25O+wao81Q2K8SPjr/ QfFfruhFNIpJYySu0dr2dhFqu83Jq8z6DyBE3rXkpkbOUVP1oI5dqIIP7is5reS0DHD4Gs5CgGI D05IkuWDSYikw0B5orjUcyZ6SBEBH4jJKwuSR2ZaU X-Gm-Gg: ASbGncsTmsGb0Y+PRfum0tQeok+KS8uLpTSJ89eJse80thhz6xxC76To16vFV3pW39m bm4HiDGZzi0reMKWpZDCWBKcbqPwDrSC7iLhkGTnZZxWe0pnE56GzlgLGag6y6hnSEmwRYsc2sO Hr+knC0yhlI9IG7SUQfV3w+rj07R5FVTGdKI4oQJelmPnrp+WHpZ1bppvaIYViJF8yzSdMLJa5G f8= X-Google-Smtp-Source: AGHT+IH6fVu3kc1LHhY0WLz6SMRAI1DYB0Qx1UNZHTLMuzqJ3eAvGOift1Je6fadKbOCVocb+sv+6Dh/tKBSZvaKClw= X-Received: by 2002:a05:622a:8e0a:b0:4a7:ff6d:e956 with SMTP id d75a77b69052e-4a9ec7d20b7mr1720491cf.3.1752126852575; Wed, 09 Jul 2025 22:54:12 -0700 (PDT) MIME-Version: 1.0 References: <20250610233053.973796-1-cachen@purestorage.com> <3c9b5773-83ed-4f13-11a8-fcc162c8c483@google.com> In-Reply-To: <3c9b5773-83ed-4f13-11a8-fcc162c8c483@google.com> From: Sourav Panda Date: Wed, 9 Jul 2025 22:54:00 -0700 X-Gm-Features: Ac12FXyaRdeLntAIQEIZ4cd__y1aYV_48k84kwCaGUCeCv7hvCMu5cSVNB4I6bI Message-ID: Subject: Re: [PATCH] alloc_tag: add per-NUMA node stats To: David Rientjes Cc: Kent Overstreet , Casey Chen , Andrew Morton , surenb@google.com, corbet@lwn.net, dennis@kernel.org, tj@kernel.org, cl@gentwo.org, Vlastimil Babka , mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 8kuyusc3kyxzdisc4cjrf1ufysd6trht X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: B872340013 X-HE-Tag: 1752126853-724468 X-HE-Meta: U2FsdGVkX18pjM9h7vZYS/bf2b16Byh0Vv8Y94v+ze9WiXE9DnfjiJ7Eb/1oeY4CiV2PgUXqOVZ797yxENSzRCht5cTD7SI0eE9DXWxwWuhXDSb0TJ8GWiJzkTC0Wo7HwqFr+lWLHTBX1HFfb7RF8aE4ANLX1rew6CCXFSUcTzSk4l+LCjn/B/QolOASun+RLGS9zoaYGQpaKAQXIJRCi3UrUnZmqeKlqkgv0LIPh0bWTO/NAzO/oFaW8OXzqIbH6+xUwwEL4Ei2wHqmVH3XuzS+e3HldKUfttB7b65kUlO5B+VPtlqUCkQEZlbxyUa39VOm5iqP4ONCinIDMMBAGZyCfReVLRLDUt9oHXlpqMgM4DwdgQozzQFXXg40SKQXFLGbVXpP1gJHpLg3dLenFIZ0XmjsyqN4n+S5lsc0fFig7dhLfRSBecPCbjhJD3dx77rgrxuoSaD5vPNKqeWrJNnQYZjPhVqDZZQlWqXtO8wdzJmI5aQ8anPHT7EqmazGsH8aqKVUf8vY0y4TpuSWqH6uM45omnXS+PpK1dGpYaRJqkCWPZfb0pzr1nXzhRlrADFLExhVq7O2d6rx02U+QSKbm6SRYpSIsvBBvDtqBvlZtbQA0RCVpyL6g9WW2O08+AJeq1O0Fzf/mVMTUKqyf93ndydEOwdd/vgtMJVsSPif+VG2Vgp3m2s15/BdOr5PWYdnAFyT5RQJ6Hloho7rFF7q7rMAK7rYJPl0+H9iEfKJwyYpmDhyG4fn0E+cid4+kElpL4Tm4+7UkCOEzo+Qzfotj5YKy5O56wR14yH7zyr+8qM/njxz5wMWToZcb7Y1624iHvb7Nvv3Un5ElJXN4cgW6QKugb0RVWiZclSpsze2hpmga80TisJIDexKjOYPmWvDVGo18YWsbyXYLbhWJrQx+VG5N16A4DoO51CJf7QyzTFK6S6hYPvITLhYZzbZFFhJuAMSCYk= 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, Jul 8, 2025 at 2:52=E2=80=AFPM David Rientjes = wrote: > > On Wed, 18 Jun 2025, Kent Overstreet wrote: > > > On Tue, Jun 10, 2025 at 05:30:53PM -0600, Casey Chen wrote: > > > Add support for tracking per-NUMA node statistics in /proc/allocinfo. > > > Previously, each alloc_tag had a single set of counters (bytes and > > > calls), aggregated across all CPUs. With this change, each CPU can > > > maintain separate counters for each NUMA node, allowing finer-grained > > > memory allocation profiling. > > > > > > This feature is controlled by the new > > > CONFIG_MEM_ALLOC_PROFILING_PER_NUMA_STATS option: > > > > > > * When enabled (=3Dy), the output includes per-node statistics follow= ing > > > the total bytes/calls: > > > > > > > > > ... > > > 315456 9858 mm/dmapool.c:338 func:pool_alloc_page > > > nid0 94912 2966 > > > nid1 220544 6892 > > > 7680 60 mm/dmapool.c:254 func:dma_pool_create > > > nid0 4224 33 > > > nid1 3456 27 > > > > I just received a report of memory reclaim issues where it seems DMA32 > > is stuffed full. > > > > So naturally, instrumenting to see what's consuming DMA32 is going to b= e > > the first thing to do, which made me think of your patchset. > > > > I wonder if we should think about something a bit more general, so it's > > easy to break out accounting different ways depending on what we want t= o > > debug. > > > > Right, per-node memory attribution, or per zone, is very useful. > > Casey, what's the latest status of your patch? Using alloc_tag for > attributing memory overheads has been exceedingly useful for Google Cloud > and adding better insight it for per-node breakdown would be even better. > > Our use case is quite simple: we sell guest memory to the customer as > persistent hugetlb and keep some memory on the host for ourselves (VMM, > host userspace, host kernel). We track every page of that overhead memor= y > because memory pressure here can cause all sorts of issues like userspace > unresponsiveness. We also want to sell as much guest memory as possible > to avoid stranding cpus. > > To do that, per-node breakdown of memory allocations would be a tremendou= s > help. We have memory that is asymmetric for NUMA, even for memory that > has affinity to the NIC. Being able to inspect the origins of memory for > a specific NUMA node that is under memory pressure where other NUMA nodes > are not under memory pressure would be excellent. > > Adding Sourav Panda as well as he may have additional thoughts on this. I agree with David, especially the point regarding NIC affinity. I was dealing with a similar bug today, but pertaining to SSD where this patchset would have helped in the investigation. That being said, I think pgalloc_tag_swap() has to be modified as well, which gets called by __migrate_folio().