Re: [RFC PATCH v1 0/7] Open HugeTLB allocation routine for more generic use

[Joshua Hahn <joshua.hahnjy@gmail.com>]

On Wed, 11 Feb 2026 16:37:11 -0800 Ackerley Tng <ackerleytng@google.com> wrote:

Hi Ackerly, I hope you're donig well!

[...snip...]

> I would like to get feedback on:
> 
> 1. Opening up HugeTLB's allocation for more generic use

I'm not entirely familiar with guest_memfd, so pleae excuse my ignorance
if I'm missing anything obvious. But I'm wondering what hugeTLB offers
that other hugepage solutions cannot offer for guest_memfd, if the
goal of this series is to decouple it from hugeTLBfs.

> 2. Reverting and re-adopting the try-commit-cancel protocol for memory
>    charging

On the second point, I am wondering if reintroducing the try-commit-cancel
protocol is tied to factoring out hugetlb_alloc_folio. When I removed
the protocol a while back, the justification was that for the most part,
grabbing a hugetlb folio was a relatively cheap & fast operation, since
hugetlb mostly operates out of a preallocated pool.

So the cost of being wrong, going above the limit, and having to return
the hugetlb folio was also relatively low.

It seems like this patch series introduces some new paths for hugetlb
pages to be consumed (specifically, without a reservation or vma).
I imagine that these new paths make the slowpath for hugetlb more frequent,
which makes the cost of assuming that the memcg limit is OK higher?
I think explicitly spelling this out in the justification for reintroducing
the charging protocol could be helpful. 

Thank you for the series, again. I hope you have a great day!
Joshua

> 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.ackerleytng@google.com/T/
> [2] https://github.com/googleprodkernel/linux-cc/tree/wip-gmem-conversions-hugetlb-restructuring-12-08-25
> 
> 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
>