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 D7994C4828F for ; Thu, 8 Feb 2024 18:36:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 57C346B0078; Thu, 8 Feb 2024 13:36:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 52CF96B007D; Thu, 8 Feb 2024 13:36:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 423ED6B007E; Thu, 8 Feb 2024 13:36:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2D21E6B0078 for ; Thu, 8 Feb 2024 13:36:21 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id F1A38A2555 for ; Thu, 8 Feb 2024 18:36:20 +0000 (UTC) X-FDA: 81769491720.04.C0A2B48 Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) by imf12.hostedemail.com (Postfix) with ESMTP id 2FB2740004 for ; Thu, 8 Feb 2024 18:36:18 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="bznlw/sN"; spf=pass (imf12.hostedemail.com: domain of souravpanda@google.com designates 209.85.218.41 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=1707417379; 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=xsrCAeH2n9ceQiPxPn8Ek/uBDISn4oWieyAkWRJRATU=; b=38q+fcvZD9J47UGMM4LIcgqyKASXKg7y99fqdC86PmVd5iy4JnZlOx44IdVhACk+8hEBQ1 vFHvi0q87bzIItj1w1QXcwMPR3n9Ft244wFuSk/hxBNa88NdZHA08pVDZbPhrh7qlhUyIl foeKkXGWwUqbJ5ddIN+KctkOmmIIT5A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707417379; a=rsa-sha256; cv=none; b=Ic3Wi96scIuF9gYRsGSmVoOLar0rSn+YFuB+zPTfWN8v6sjbXCNl8tAZOmpNpYenK4e+kP 75uBw6BwIl60FOOncOwCP2l7JaGPuKm0f7/seBOzfYLoFJNK/+bSqIK7e4fxVh+qBWSwdW P1uSgVCkSdednYdhMMz+onUpELPJ5ps= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="bznlw/sN"; spf=pass (imf12.hostedemail.com: domain of souravpanda@google.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=souravpanda@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-a3864258438so30912666b.0 for ; Thu, 08 Feb 2024 10:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707417377; x=1708022177; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xsrCAeH2n9ceQiPxPn8Ek/uBDISn4oWieyAkWRJRATU=; b=bznlw/sN74ivqDNryw8V13Tf8ZIZWN2OAq/B9rADG1wJdxI3c6wflsiX1/m1oYPxYx r6EkGms8VVVrcZKtLaVBILda1RAO6qUwbSN/yi+bVibOyLbc9G69uHPUh38yoIDUh1KJ 5jjtmvaSrCwn8CiHDLFEi6MX2aEATBMzBCEVHEeFAoOpnVeguKqLmtXauQ+XWEp0wrTs kif8iJMbmpZF5vrcstja+4+YDCC4USY9vWWzalN1/rBN9hyH2x9yohgMFQPz9Eic+KO6 bOPYcVjwqOa9lVbfFGi6gwMPaLke6LKgV2op5Il84SO8VLiaY4zE1RexEt8ofuokLDbt af3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707417377; x=1708022177; h=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=xsrCAeH2n9ceQiPxPn8Ek/uBDISn4oWieyAkWRJRATU=; b=S/Jsfb2nk9N5J+6r0d0I0Z+7J3HLdnbsQqGo2CKQKpL6dE0rV+4saj37LVuX820wTh +WAWMNnkehRluQWDMKnS/ep3/jBkA5Tk/rH50hGDwKZ4fU1iIioGGdlyTqcX1FJS5Am7 yoTecLlQicymbx1TqZAZI6bUskg4Sw5JrHqPsE4WVRx6OMvCBAwYbTu9GtPlPkSiK8i3 zl45VcAOMLOUbiwNMavKVLG6iDMDNrFku23olMoeDf1yizbCcN8YgpufWpqbaRohcYn8 IYPZuLk1wqsAKoWL99FjZRwWOfOzxkx0ma4gpTMbtOay4B3crSSCI+hVJrdWfQxWBu9W iZuA== X-Forwarded-Encrypted: i=1; AJvYcCWqwkipHSCFtRzulNzTvtCyfuY9IgRDQpKDdFWJ+tNP4Ku1zpyal8ytdgxvKEL8lZf/l2KFvZ9zXFOu6aP1euo9wpc= X-Gm-Message-State: AOJu0Yw4WNt8rKAtKbLZe5SSS9qbtYjmhww2IhbOQ2jtgknMOHW9Usxe OQD1UO88QJ8L4qtMtvQw0j7zSA0bwkxMDKXteMOw7e4IYuzB8au5ILclhbPvne1BwLwjsJ30gbz TqYs7spnoo8dgEOSpmTyCL8ZhSuZBRGRmj37X X-Google-Smtp-Source: AGHT+IEprIk7IfAje+2PUmE3+EBn1EHsQAsaRvCxo3xEPW54VTq80TrrQrWC2utEt9iWksAlXvReo6Si44kn6SBJgs4= X-Received: by 2002:a17:906:1b15:b0:a38:32bc:bd24 with SMTP id o21-20020a1709061b1500b00a3832bcbd24mr2614742ejg.36.1707417377482; Thu, 08 Feb 2024 10:36:17 -0800 (PST) MIME-Version: 1.0 References: <20240129224204.1812062-1-souravpanda@google.com> <20240207150503.ca18b372f899091af5e6c40b@linux-foundation.org> In-Reply-To: <20240207150503.ca18b372f899091af5e6c40b@linux-foundation.org> From: Sourav Panda Date: Thu, 8 Feb 2024 10:36:05 -0800 Message-ID: Subject: Re: [PATCH v7 0/1] mm: report per-page metadata information To: Andrew Morton Cc: corbet@lwn.net, gregkh@linuxfoundation.org, rafael@kernel.org, mike.kravetz@oracle.com, muchun.song@linux.dev, rppt@kernel.org, david@redhat.com, rdunlap@infradead.org, chenlinxuan@uniontech.com, yang.yang29@zte.com.cn, tomas.mudrunka@gmail.com, bhelgaas@google.com, ivan@cloudflare.com, pasha.tatashin@soleen.com, yosryahmed@google.com, hannes@cmpxchg.org, shakeelb@google.com, kirill.shutemov@linux.intel.com, wangkefeng.wang@huawei.com, adobriyan@gmail.com, vbabka@suse.cz, Liam.Howlett@oracle.com, surenb@google.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, willy@infradead.org, weixugc@google.com Content-Type: multipart/alternative; boundary="000000000000452e5c0610e31681" X-Rspamd-Queue-Id: 2FB2740004 X-Rspam-User: X-Stat-Signature: 98bazboggb1maxisx4yjqa1h8irhbp94 X-Rspamd-Server: rspam03 X-HE-Tag: 1707417378-365623 X-HE-Meta: U2FsdGVkX1/0Eej+smd8HKZ4gm3HyEV7TCNZgx2eZEr2g5Tj4FbPOMLhhLdYRRWnxhsLj4Urehb8AYCpaTaAqh1kfKjIKdOYZlLFZtzl28l6q9OXUSyisuUVm1Iwk1vZAJtmfVL9u+qt87yZYcBTZQVJusQipdiA8sK26hsA57kkTeip5Mh/utmodx+NPTylLmtROeyxhD07PSQW3ifP06fB8y/odiKWAq+7l6/phrigYUblo3GNo+XDMA6SealULYPHTm4a9sCdBA5Q2RMmW8as2cUYtazQm6YA0/f6R0sF70oeR/tC+9No4pdjq5qHbfV6fGJJBMYo29J3kAcVHGC23iEMRQFOyxuDB3tKULYEuMiU9Py1T09hEl06MXmAt2SS25JB8LGG+wfyU0DBRIOGNK8YQcul4o+PLVC8iXij+QnVDQlgIbpQzRrRUmx/KaI2jlSLAkK+XdxbO2wbgYKrp2YpWExWKS9YOUsS6NNEKo+chiTwourAW+bvaepQC7G30Ktl01CBB6B0OU76m2zebeKsihbexAIUkoXdaY69hDWf+ALf7yxUcR4unDkHqZnYkJ/JylJf1yNoqYhtdjc0yG2lLXXsDJEj6VGfLgJTKFPpXTrkmpw4JJVun7I61cZYcFJL9oBFHTSY0I/VLbe0iI7VjpRB2WotsCQwTbNDIXarndda6zneMtFm+4ex4K0sZ+Z3ZWi9+7q8TvpqQY2CRbYmEIy19HL+MrFZgifvEsxzl8NQ6Jm8VMaNgyFM8aMzucx1GdhvrTN5o/NYShA5jn8bkLiaANW4dJQVw0VpqLZEzhDSwHZ7bUpG81L7RRZraAq07JjsI6NYYaJNWuE/QZvMiBSHifq6MHd7obhVspyoyX9TTCSkrB5sE9ADsUH5nPLJy4SM7jiy/9bygG52bOZBoxki1UbeYDqzUzCcXcIVFbTmcaUFTCvi99xAIuOxCkTOGmhj64uuECK djBoktJP evGiYOF6BP3D+TCLQPJoRYlbYx9G8QgTZ3EesjjPNFxzP0OgIf6ESTjlBHUGEmGJu8Q6n0zEyfTFk/b31NGwKbQxmqOhlg/Hp57AzZvy6JKa/axe6jQ8qZeId6LaEB6WPJ03KMWnzi//qprKsESxsaUIoxXG6OI34HObZAVTgLytmgM7SodjphWdcekPRS7o8hSL1DeoeeGOfFjapAH6s1+qwoHomfXAI64aj/U/Su3O7JPO6xw8O/NoCD+bBdKK1ELb3DRMahxT1e+qSwtTb0uBJfp2TxzZGk412wjgF1IaeX1Rz9pzjMJe9uHB4OH5JyQiMAslXPBEDXVipL9ay2uulpfq/GFhe9CBxqOKch+awWKMNuLkssunFZJGS2+Rbn3CiyCYtYqkgrqTImHFyDXcP9xLxAxQi8L/g3ubRSmTwFX9QtaElZrJGi7eIbG1I/TLgqfBrloUMqcm+b+M+bV5Mmzn/J3zdBVGwDXyBPFDl32Y= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000008, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --000000000000452e5c0610e31681 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 7, 2024 at 3:05=E2=80=AFPM Andrew Morton wrote: > On Mon, 29 Jan 2024 14:42:03 -0800 Sourav Panda > wrote: > > > This patch adds two new per-node fields, namely nr_page_metadata and > > nr_page_metadata_boot to /sys/devices/system/node/nodeN/vmstat and a > > global PageMetadata field to /proc/meminfo. This information can be > > used by users to see how much memory is being used by per-page > > metadata, which can vary depending on build configuration, machine > > architecture, and system use. > > I'm not seeing why this is very useful. OK, you look at it and it > tells you a number, but what action can a user take based upon that > number? > > Please tell us more about the value of this, the use cases, what > prompted you to expend effort on this. > Hi Andrew, Thank you for looking into this. Application Optimization: Depending on the kernel version and command line options, the kernel would relinquish a different number of pages (that contain struct pages) when a hugetlb page is reserved (e.g., 0, 6 or 7 for a 2MB hugepage). The userspace application would want to know the exact savings achieved through page metadata deallocation without dealing with the intricacies of the kernel. Observability: Struct page overhead can only be calculated on-paper at boot time (e.g., 1.5% machine capacity). Beyond boot once hugepages are reserved or memory is hotplugged, the computation becomes complex. Per-page metrics will help explain part of the system memory overhead, which shall help guide memory optimizations and memory cgroup sizing. Debugging: Tracking the changes or absolute value in struct pages can help detect anomalies as they can be correlated with other metrics in the machine (e.g., memtotal, number of huge pages, etc). page_ext overheads: Some kernel features such as page_owner page_table_check that use page_ext can be optionally enabled via kernel parameters. Having the total per-page metadata information helps users precisely measure impact. In the version 8, that I will send out soon, I'll integrate the above into the commit log. Also, following Johannes Weiner's suggestion, I'll rename nr_page_metadata to nr_memmap. Thank you, Sourav --000000000000452e5c0610e31681 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 7, 2024 at 3:05=E2=80=AFP= M Andrew Morton <akpm@linux= -foundation.org> wrote:
On Mon, 29 Jan 2024 14:42:03 -0800 Sourav Panda <souravpanda@google.com= > wrote:

> This patch adds two new per-node fields, namely nr_page_metadata and > nr_page_metadata_boot to /sys/devices/system/node/nodeN/vmstat and a > global PageMetadata field to /proc/meminfo. This information can be > used by users to see how much memory is being used by per-page
> metadata, which can vary depending on build configuration, machine
> architecture, and system use.

I'm not seeing why this is very useful.=C2=A0 OK, you look at it and it=
tells you a number, but what action can a user take based upon that
number?

Please tell us more about the value of this, the use cases, what
prompted you to expend effort on this.

Hi An= drew,

Thank you for looking into this.

Application Optimizati= on: Depending on the kernel version and command line options, the kernel wo= uld relinquish a different number of pages (that contain struct pages) when= a hugetlb page is reserved (e.g., 0, 6 or 7 for a 2MB hugepage). The users= pace application would want to know the exact savings achieved through page= metadata deallocation without dealing with the intricacies of the kernel.<= br>
Observability: Struct page overhead can only be calculated on-paper = at boot time (e.g., 1.5% machine capacity). Beyond boot once hugepages are = reserved or memory is hotplugged, the computation becomes complex. Per-page= metrics will help explain part of the system memory overhead, which shall = help guide memory optimizations and memory cgroup sizing.

Debugging:= Tracking the changes or absolute value in struct pages can help detect ano= malies as they can be correlated with other metrics in the machine (e.g., m= emtotal, number of huge pages, etc).

page_ext overheads: Some kernel= features such as page_owner page_table_check that use page_ext can be opti= onally enabled via kernel parameters. Having the total per-page metadata in= formation helps users precisely measure impact.

In the version 8, th= at I will send out soon, I'll integrate the above into the commit log. = Also, following Johannes Weiner's suggestion, I'll rename nr_page_m= etadata to nr_memmap.

Thank you,
Sourav
=C2=A0
--000000000000452e5c0610e31681--