[LSF/MM/BPF TOPIC][RFC PATCH 0/2] Hugetlb Fungibility for page metadata savings and network performance

[Sourav Panda <souravpanda@google.com>]

The purpose of this RFC is to supplement our discussion in LSF/MM-26.

This is sent as a proof of concept. It applies on top of v7.0-rc3.

In VM environments, the guest frequently utilizes 1GB HugeTLB pages to
reduce TLB misses and minimize page table walk overhead for
network-functions. This has the added benefit that it reduces redundant
struct page metadata overhead through Hugepage Vmemmap Optimization (HVO).

While this saves significant overhead memory, this memory is not available
for other purposes; such as the hosted VM-workload or pagecache.

The guest must balance two competing memory requirements:
HugeTLB Pool: 1GB pages reserved for high-performance NFV applications
and yielding page metadata savings.
Buddy Allocator: 4KB pages required for business logic, system services,
and page cache.

Current kernel limitations prevent fungibility of memory between these two
pools. As a starting point we propose a hugetlb-shrinker to provide one-way
fungibility wherein ~90% guest memory is allocated as 1G hugepages at boot
and then converted to buddy pages on demand.

Sourav Panda (2):
  mm: add hugepage shrinker for frozen memory
  mm/hugetlb: skip hugetlb shrinking for proactive reclaim

 include/linux/shrinker.h |   3 +
 mm/Kconfig               |   8 +++
 mm/hugetlb.c             | 131 +++++++++++++++++++++++++++++++++++++++
 mm/internal.h            |   2 +-
 mm/shrinker.c            |  12 ++--
 mm/vmscan.c              |   6 +-
 6 files changed, 154 insertions(+), 8 deletions(-)

-- 
2.53.0.959.g497ff81fa9-goog