Re: [PATCH v7 0/1] mm: report per-page metadata information

[Sourav Panda <souravpanda@google.com>]

[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]

On Wed, Feb 7, 2024 at 3:05 PM 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.  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

[-- Attachment #2: Type: text/html, Size: 2776 bytes --]