Re: [PATCH v3 6/6] mm: hugetlb: Refactor out hugetlb_alloc_folio()

["Oscar Salvador (SUSE)" <osalvador@kernel.org>]

On Mon, May 18, 2026 at 05:19:45PM -0700, Ackerley Tng via B4 Relay wrote:
> From: Ackerley Tng <ackerleytng@google.com>
> 
> Refactor out hugetlb_alloc_folio() from alloc_hugetlb_folio(), which
> handles allocation of a folio and memory and HugeTLB charging to cgroups.
> 
> This refactoring decouples the HugeTLB page allocation from VMAs,
> specifically:
> 
> 1. Reservations (as in resv_map) are stored in the vma
> 2. mpol is stored at vma->vm_policy
> 3. A vma must be used for allocation even if the pages are not meant to be
>    used by host process.
> 
> Without this coupling, VMAs are no longer a requirement for
> allocation. This opens up the allocation routine for usage without VMAs,
> which will allow guest_memfd to use HugeTLB as a more generic allocator of
> huge pages, since guest_memfd memory may not have any associated VMAs by
> design. In addition, direct allocations from HugeTLB could possibly be
> refactored to avoid the use of a pseudo-VMA.
> 
> Also, this decouples HugeTLB page allocation from HugeTLBfs, where the
> subpool is stored at the fs mount. This is also a requirement for
> guest_memfd, where the plan is to have a subpool created per-fd and stored
> on the inode.
> 
> Provide and use alloc_flags to allow more allocation knobs in future
> without expanding the number of parameters in hugetlb_alloc_folio().
> 
> No functional change intended.
> 
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>

I am traveling so I plan to do a more careful review in a few days but I
wanted to do some remark:

> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
...  
> +struct folio *hugetlb_alloc_folio(struct hstate *h, struct hugepage_subpool *spool,
> +		gfp_t gfp, struct mempolicy_interpreted *mpoli,
> +		u8 alloc_flags)
> +{
> +	bool charge_hugetlb_cgroup_rsvd = alloc_flags &
> +					  HUGETLB_ALLOC_CHARG_CGROUP_RSVD;
> +	bool use_global_reservation = alloc_flags &
> +				      HUGETLB_ALLOC_USE_GLOBAL_RESERVATIONS;
> +	size_t nr_pages = pages_per_huge_page(h);
> +	struct hugetlb_cgroup *h_cg = NULL;
> +	int idx = hstate_index(h);
> +	struct folio *folio;
> +	int ret;

IIUC, hugetlb_alloc_folio() will be the gateway function everyone will use from now
on to allocate hugetlb pages, that goes for hugetlb itself and external users like guest_memfd.

The gfp flag should really be defined here, because otherwise you are creating openings for
external users to start passing their own crafted gfp flags and that feels wrong.
Sure we can guard that down the road but we should not really need it.

 

-- 
Oscar Salvador
SUSE Labs