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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, Feb 7, 2024 at 3:05 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
On Mon, 29 Jan 2024 14:42:03 -0800 Sourav Panda <souravpanda@xxxxxxxxxx> 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
 

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux