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

[Ackerley Tng]

"Oscar Salvador (SUSE)" <osalvador@xxxxxxxxxx> writes:

> On Mon, May 18, 2026 at 05:19:45PM -0700, Ackerley Tng via B4 Relay wrote:
>> From: Ackerley Tng <ackerleytng@xxxxxxxxxx>
>>
>> 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@xxxxxxxxxx>
>
> I am traveling so I plan to do a more careful review in a few days but I
> wanted to do some remark:
>

Looking forward to the rest of your reviews!

>> --- 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.
>

Makes sense. I'll define gfp with htlb_alloc_mask(h) within
hugetlb_alloc_folio() instead of letting gfp be a parameter in the next
version.

>
>
> --
> Oscar Salvador
> SUSE Labs