Re: [PATCH v4 0/6] Open HugeTLB allocation routine for more generic use

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 02 Jul 2026 09:21:44 -0700 Ackerley Tng via B4 Relay <devnull+ackerleytng.google.com@kernel.org> wrote:

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

Thanks, I added this to mm.git's mm-new branch.

As I understand it, the entire series is code shuffling and no
functional changes are intended.

> + Addressed some of Sashiko's comments [4]. Some of the issues I didn't address
>   were pre-existing issues. Since v3 of this series Sashiko was updated to
>   actually send mails. I'd let Sashiko point them out again and then we should
>   discuss those!

Sashiko will send emails if configured to do so.  For linux-mm, that is
turned off.


https://sashiko.dev/#/patchset/20260702-hugetlb-open-up-v4-0-d53cefcccf34@google.com
says "To: None Cc: None Status: Muted", so I don't think you received
those emails (did you?).

For some reason Sashiko did flag a couple of things which it didn't
consider to be pre-existing.