Open HugeTLB allocation routine for more generic use [LWN.net]

From:		Ackerley Tng <ackerleytng-AT-google.com>
To:		akpm-AT-linux-foundation.org, dan.j.williams-AT-intel.com, david-AT-kernel.org, fvdl-AT-google.com, hannes-AT-cmpxchg.org, jgg-AT-nvidia.com, jiaqiyan-AT-google.com, jthoughton-AT-google.com, kalyazin-AT-amazon.com, mhocko-AT-kernel.org, michael.roth-AT-amd.com, muchun.song-AT-linux.dev, osalvador-AT-suse.de, pasha.tatashin-AT-soleen.com, pbonzini-AT-redhat.com, peterx-AT-redhat.com, pratyush-AT-kernel.org, rick.p.edgecombe-AT-intel.com, rientjes-AT-google.com, roman.gushchin-AT-linux.dev, seanjc-AT-google.com, shakeel.butt-AT-linux.dev, shivankg-AT-amd.com, vannapurve-AT-google.com, yan.y.zhao-AT-intel.com
Subject:		[RFC PATCH v1 0/7] Open HugeTLB allocation routine for more generic use
Date:		Wed, 11 Feb 2026 16:37:11 -0800
Message-ID:		<cover.1770854662.git.ackerleytng@google.com>
Cc:		ackerleytng-AT-google.com, cgroups-AT-vger.kernel.org, linux-kernel-AT-vger.kernel.org, linux-mm-AT-kvack.org
Archive-link:		Article

Hi,

The motivation for this patch series is guest_memfd, which would like
to use HugeTLB as a generic source of huge pages but not adopt
HugeTLB's reservation at mmap() time.

By refactoring alloc_hugetlb_folio() and some dependent functions,
there is now an option to allocate HugeTLB folios without providing a
VMA. Specifically, HugeTLB allocation used to be dependent on the VMA
to

1. Look up reservations in the resv_map
2. Get mpol, stored at vma->vm_policy

This refactoring provides hugetlb_alloc_folio(), which focuses on just
the allocation itself, and associated memory and HugeTLB charging
(cgroups). alloc_hugetlb_folio() still handles reservations in the
resv_map and subpools.

Regarding naming, I'm definitely open to alternative names :) I chose
hugetlb_alloc_folio() because I'm seeing this function as a general
allocation function that is provided by the HugeTLB subsystem (hence
the hugetlb_ prefix). I'm intending for alloc_hugetlb_folio() to be
later refactored as a static function for use just by HugeTLB, and
HugeTLBfs should probably use hugetlb_alloc_folio() directly.

I would like to get feedback on:

1. Opening up HugeTLB's allocation for more generic use
2. Reverting and re-adopting the try-commit-cancel protocol for memory
   charging

To see how hugetlb_alloc_folio() is used by guest_memfd, the most
recent patch series that uses this more generic HugeTLB allocation
routine is at [1], and a newer revision of that patch series is at
[2].

Independently of guest_memfd, I believe this change is useful in
simplifying alloc_hugetlb_folio(). alloc_hugetlb_folio() was so
coupled to a VMA that even HugeTLBfs allocates HugeTLB folios using a
pseudo-VMA.

[1] https://lore.kernel.org/all/cover.1747264138.git.ackerley...
[2] https://github.com/googleprodkernel/linux-cc/tree/wip-gme...

Ackerley Tng (7):
  mm: hugetlb: Consolidate interpretation of gbl_chg within
    alloc_hugetlb_folio()
  mm: hugetlb: Move mpol interpretation out of
    alloc_buddy_hugetlb_folio_with_mpol()
  mm: hugetlb: Move mpol interpretation out of
    dequeue_hugetlb_folio_vma()
  Revert "memcg/hugetlb: remove memcg hugetlb try-commit-cancel
    protocol"
  mm: hugetlb: Adopt memcg try-commit-cancel protocol
  mm: memcontrol: Remove now-unused function mem_cgroup_charge_hugetlb
  mm: hugetlb: Refactor out hugetlb_alloc_folio()

 include/linux/hugetlb.h    |  11 ++
 include/linux/memcontrol.h |  21 +++-
 mm/hugetlb.c               | 228 +++++++++++++++++++++----------------
 mm/memcontrol.c            |  77 ++++++++-----
 4 files changed, 212 insertions(+), 125 deletions(-)


base-commit: db9571a66156bfbc0273e66e5c77923869bda547
--
2.53.0.310.g728cabbaf7-goog