lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240214225741.403783-1-souravpanda@google.com>
Date: Wed, 14 Feb 2024 14:57:39 -0800
From: Sourav Panda <souravpanda@...gle.com>
To: corbet@....net, gregkh@...uxfoundation.org, rafael@...nel.org, 
	akpm@...ux-foundation.org, mike.kravetz@...cle.com, muchun.song@...ux.dev, 
	rppt@...nel.org, david@...hat.com, rdunlap@...radead.org, 
	chenlinxuan@...ontech.com, yang.yang29@....com.cn, souravpanda@...gle.com, 
	tomas.mudrunka@...il.com, bhelgaas@...gle.com, ivan@...udflare.com, 
	pasha.tatashin@...een.com, yosryahmed@...gle.com, hannes@...xchg.org, 
	shakeelb@...gle.com, kirill.shutemov@...ux.intel.com, 
	wangkefeng.wang@...wei.com, adobriyan@...il.com, vbabka@...e.cz, 
	Liam.Howlett@...cle.com, surenb@...gle.com, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-doc@...r.kernel.org, linux-mm@...ck.org, 
	willy@...radead.org, weixugc@...gle.com
Subject: [PATCH v8 0/1] mm: report per-page metadata information

Changelog:
v8:
	- Addressed Powerpc (Power8 LE) boot failure.
	  	- In __populate_section_memmap instead of calling
		  mod_node_page_state (unavaialable at boot for
		  powerpc), we call mod_node_early_perpage_metadata.
		  This was a helper function that was introduced
		  for arm, to combat this exact problem.
		- Since __populate_section_memmap is tagged with
		  __meminit, we also had to modify the tag of
		  mod_node_early_perpage_metadata from __init to
		  __meminit.
	- Naming Changes:
	  	- In /proc/meminfo PageMetadata --> Memmap
		- In /proc/vmstat  nr_page_metadata --> nr_memmap
		- In /proc/vmstat  nr_page_metadata_boot -->
		  nr_memmap_boot
	- Addressed clarifications requested by Andrew Morton.
	  	- Updated the commit log to include utility or
		  potential usage for userspace.
	- Declined changing  placement of metrics after attempting:
		- No changes in /proc/meminfo since it cannot be moved
		  to the end anyway. This is because we have also
		  hugetlb_report_meminfo() and arch_report_meminfo().
	- Rebased to version 6, patchlevel 8.
v7:
	- Addressed comments from David Rientjes
                - For exporting PageMetadata to /proc/meminfo,
                  utilize global_node_page_state_pages for item
                  NR_PAGE_METADATA. This is instead of iterating
                  over nodes and accumulating the output of
                  node_page_state.
v6:
	- Interface changes
	  	- Added per-node nr_page_metadata and
		  nr_page_metadata_boot fields that are exported
		  in /sys/devices/system/node/nodeN/vmstat
		- nr_page_metadata exclusively tracks buddy
		  allocations while nr_page_metadata_boot
		  exclusively tracks memblock allocations.
		- Modified PageMetadata in /proc/meminfo to only
		  include buddy allocations so that it is
		  comparable against MemTotal in /proc/meminfo
		- Removed the PageMetadata field added in
		  /sys/devices/system/node/nodeN/meminfo
	- Addressed bugs reported by the kernel test bot.
	  	- All occurences of __mod_node_page_state have
		  been replaced by mod_node_page_state.
	- Addressed comments from Muchun Song.
	  	- Removed page meta data accouting from
		  mm/hugetlb.c. When CONFIG_SPARSEMEM_VMEMMAP
		  is disabled struct pages should not be returned
		  to buddy.
	- Modified the cover letter with the results and analysis
		- From when memory_hotplug.memmap_on_memory is
		  alternated between 0 and 1.
		- To account for the new interface changes.

v5:
	- Addressed comments from Muchun Song.
		- Fixed errors introduced in v4 when
		  CONFIG_SPARSEMEM_VMEMMAP is disabled by testing
		  against FLATMEM and SPARSEMEM memory models.
		- Handled the condition wherein the allocation of
		  walk.reuse_page fails, by moving NR_PAGE_METADATA
		  update into the clause if( walk.reuse_page ).
		- Removed the usage of DIV_ROUND_UP from
		  alloc_vmemmap_page_list since "end - start" is
		  always a multiple of PAGE_SIZE.
		- Modified alloc_vmemmap_page_list to update
		  NR_PAGE_METADATA once instead of every loop.
v4:
	- Addressed comment from Matthew Wilcox.
		- Used __node_stat_sub_folio and __node_stat_add_folio
		  instead of __mod_node_page_state in mm/hugetlb.c.
		- Used page_pgdat wherever possible in the entire patch.
		- Used DIV_ROUND_UP() wherever possible in the entire
		  patch.
v3:
	- Addressed one comment from Matthew Wilcox.
	  	- In free_page_ext, page_pgdat() is now extracted
		  prior to freeing the memory.
v2:
	- Fixed the three bugs reported by kernel test robot.
	- Enhanced the commit message as recommended by David Hildenbrand.
	- Addressed comments from Matthew Wilcox:
	  	- Simplified alloc_vmemmap_page_list() and
		  free_page_ext() as recommended.
		- Used the appropriate comment style in mm/vmstat.c.
		- Replaced writeout_early_perpage_metadata() with
		  store_early_perpage_metadata() to reduce ambiguity
		  with what swap does.
	- Addressed comments from Mike Rapoport:
	  	- Simplified the loop in alloc_vmemmap_page_list().
		- Could NOT address a comment to move
		  store_early_perpage_metadata() near where nodes
		  and page allocator are initialized.
		- Included the vmalloc()ed page_ext in accounting
		  within free_page_ext().
		- Made early_perpage_metadata[MAX_NUMNODES] static.


Previous approaches and discussions
-----------------------------------
V7:
https://lore.kernel.org/all/20240129224204.1812062-1-souravpanda@google.com
V6:
https://lore.kernel.org/all/20231205223118.3575485-1-souravpanda@google.com
v5:
https://lore.kernel.org/all/20231101230816.1459373-1-souravpanda@google.com
v4:
https://lore.kernel.org/all/20231031223846.827173-1-souravpanda@google.com
v3:
https://lore.kernel.org/all/20231031174459.459480-1-souravpanda@google.com
v2:
https://lore.kernel.org/all/20231018005548.3505662-1-souravpanda@google.com
v1:
https://lore.kernel.org/r/20230913173000.4016218-2-souravpanda@google.com

Hi!

This patch adds two new per-node fields, namely nr_memmap and
nr_memmap_boot to /sys/devices/system/node/nodeN/vmstat and a
global Memmap 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.

Per-page metadata is the amount of memory that Linux needs in order to
manage memory at the page granularity. The majority of such memory is
used by "struct page" and "page_ext" data structures.


Background
----------

Kernel overhead observability is missing some of the largest
allocations during runtime, including vmemmap (struct pages) and
page_ext. This patch aims to address this problem by exporting a
new metric Memmap.

On the contrary, the kernel does provide observibility for boot memory
allocations. For example, the metric reserved_pages depicts the pages
allocated by the bootmem allocator. This can be simply calculated as
present_pages - managed_pages, which are both exported in /proc/zoneinfo.
The metric reserved_pages is primarily composed of struct pages and
page_ext.

What about the struct pages (allocated by bootmem allocator) that are
free'd during hugetlbfs allocations and then allocated by buddy-allocator
once hugtlbfs pages are free'd?

/proc/meminfo MemTotal changes: MemTotal does not include memblock
allocations but includes buddy allocations. However, during runtime
memblock allocations can be shifted into buddy allocations, and therefore
become part of MemTotal.

Once the struct pages get allocated by buddy allocator, we lose track of
these struct page allocations overhead accounting. Therefore, we must
export new metrics. nr_memmap and nr_memmap_boot exclusively track the
struct page and page ext allocations made by the buddy allocator and
memblock allocator, respectively for each node. Memmap in /proc/meminfo
would report the struct page and page ext allocations made by the buddy
allocator.

Results and analysis
--------------------

Memory model: Sparsemem-vmemmap
$ echo 1 > /proc/sys/vm/hugetlb_optimize_vmemmap

$ cat /proc/meminfo | grep MemTotal
	MemTotal:       32919124 kB
$ cat /proc/meminfo | grep Memmap
	Memmap:		   65536 kB
$ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap"
	nr_memmap 8192
	nr_memmap_boot 65536
$ cat /sys/devices/system/node/node1/vmstat | grep "nr_memmap"
        nr_memmap 8192
	nr_memmap_boot 65536

AFTER HUGTLBFS RESERVATION
$ echo 512 > /proc/sys/vm/nr_hugepages

$ cat /proc/meminfo | grep MemTotal
	MemTotal:       32935508 kB
$ cat /proc/meminfo | grep Memmap
	Memmap:      67584 kB
$ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap"
	nr_memmap 8448
	nr_memmap_boot  63488
$ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap"
	nr_memmap 8448
	nr_memmap_boot  63488


AFTER FREEING HUGTLBFS RESERVATION
$ echo 0 > /proc/sys/vm/nr_hugepages

$ cat /proc/meminfo | grep MemTotal
        MemTotal:       32935508 kB
$ cat /proc/meminfo | grep Memmap
        Memmap:      81920 kB
$ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap"
        nr_memmap 10240
	nr_memmap_boot  63488
$ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap"
        nr_memmap 10240
	nr_memmap_boot  63488

------------------------

Memory Hotplug with memory_hotplug.memmap_on_memory=1

BEFORE HOTADD
$ cat /proc/meminfo | grep MemTotal
	MemTotal:       32919124 kB
$ cat /proc/meminfo | grep Memmap
	Memmap:      65536 kB
$ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap"
	nr_memmap 8192
	nr_memmap_boot  65536
$ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap"
	nr_memmap 8192
	nr_memmap_boot  65536

AFTER HOTADDING 1GB
$ cat /proc/meminfo | grep MemTotal
	MemTotal:       33951316 kB
$ cat /proc/meminfo | grep Memmap
	Memmap:      83968 kB
$ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap"
	nr_memmap 12800
	nr_memmap_boot 65536
$ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap"
	nr_memmap 8192
	nr_memmap_boot 65536

--------------------------

Memory Hotplug with memory_hotplug.memmap_on_memory=0

BEFORE HOTADD
$ cat /proc/meminfo | grep MemTotal
	MemTotal:       32919124 kB
$ cat /proc/meminfo | grep Memmap
	Memmap:      65536 kB
$ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap"
	nr_memmap 8192
	nr_memmap_boot 65536
$ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap"
	nr_memmap 8192
	nr_memmap_boot 65536

AFTER HOTADDING 1GB
$ cat /proc/meminfo | grep MemTotal
	MemTotal:       33967700 kB
$ cat /proc/meminfo | grep Memmap
	Memmap:      83968 kB
$ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap"
	nr_memmap 12800
	nr_memmap_boot 65536
$ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap"
	nr_memmap 8192
	nr_memmap_boot 65536

Sourav Panda (1):
  mm: report per-page metadata information

 Documentation/filesystems/proc.rst |  3 +++
 fs/proc/meminfo.c                  |  4 ++++
 include/linux/mmzone.h             |  4 ++++
 include/linux/vmstat.h             |  4 ++++
 mm/hugetlb_vmemmap.c               | 17 ++++++++++++----
 mm/mm_init.c                       |  3 +++
 mm/page_alloc.c                    |  1 +
 mm/page_ext.c                      | 32 +++++++++++++++++++++---------
 mm/sparse-vmemmap.c                |  8 ++++++++
 mm/sparse.c                        |  7 ++++++-
 mm/vmstat.c                        | 26 +++++++++++++++++++++++-
 11 files changed, 94 insertions(+), 15 deletions(-)

-- 
2.43.0.687.g38aa6559b0-goog


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ