Re: [RFC PATCH 0/8] Introducte Reserved THP

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Thu, Aug 13, 2026 at 12:00:30PM +0200, David Hildenbrand (Arm) wrote:
> ... digging through old mail.
>
> >
> > You mean the reservation should be done via some file handle, like
> > memfd, so that it is easy to apply memory policies to determine where
> > reserved memory locates?
> >
> > For existing hugetlb reservation, there is no fine control, like NUMA,
> > or cgroup, of the reserved free memory.
> >
> > Is that what you mean above?
>
> I guess, it's all tricky. hugetlb reservation is a mess. We better not make
> similar mistakes with THPs.
>
> [...]
>
> >>> 3.6 Remove Hugetlb
> >>> ------------------
> >>>
> >>> Once reserved THP can completely replace the existing functions of hugetlb, we
> >>> can gradually remove Hugetlb, leaving only one huge page management system in
> >>> the kernel.
> >>
> >> I'm sorry, but no way this will work in any reasonable timeframe unless you
> >> mimic the exact user facing ABI -- and I don't think we'll gain a lot that way.
> >>
> >> I know, we all like to dream, but this just isn't feasible.
> >
> > Based on my understanding, the key takeway is that we want to have more
> > control over reserved memory, where to get the free memory, who gets how
> > much of the reserved memory, and more.
>
> yes, it's all very complicated. Slapping on some MADV_RESERVED_THP is just
> entirely the wrong way to tackle this.

I agree with David that this series is a no-go, and there are many levels of
complexity here:

- What does reservation really mean in a context where any process can indicate
  desire for THP huge pages through MADV_HUGEPAGE or more big-hammer-ly
  MADV_COLLAPSE? Let alone mapping in THP-aligning file system's files or edge
  cases like DAX or soon, huge pfn mappings once I do that series.

- There's no sense of ownership, and as David says NUMA makes everything more
  complicated. And that's before we even get on to memcg.

- We have a flaming trashpile of a codebase that needs improving. There are
  (thankfully) efforts afoot on this front, but big new shiny features are as
  far as I am concerned on pause until technical debt is paid down _anyway_.

- We have a flaming trashpile of an API which we must keep intact despite it
  having many contradictions, edge cases and points of confusion.

I mean the list goes on.

Also it feels like reservation is almost throwing up our arms and giving up on
improving compaction which is part of the problem here - stalls have been seen
in real world use cases with even /sys/kernel/mm/transparent_hugepage/defrag set
to madvise let alone anything else - and I feel are part of why people want ways
around things.

I also think the idea of reserved memory flies in the face of THP on principle -
the 'T' stands for transparent :) but in general, as David says, hugetlb is a
horror show and a terrible maintenance headache (look at the recent hugetlb hw
poison stuff for an example of this), and mimicing anything it does is already a
dangerous road to take.

As usual we keep coming back to the same broader points:

- How to control the resource that is large folios in a sensible way that allows
  some semblence of control over this.

- Do we want to give more control or be more automatic? How do we achieve a
  balance and what metrics should we use?

- How do we even accurately measure all of this?

- and let's improve compaction/migration :)

These are all bikeshed-able, lead to endless discussions and I think are
fruitless at this stage - right now we have a mess, firstly let's improve that
mess and establish some foundations to build on iteratively.

I am really rather against big concept stuff in THP to be honest and more in
favour of small, incremental _improvements_ to what we already have.

And feature-wise, 1 GiB THP is on the horizon and as David says figuring that
out sensibly should be instructive.

But notice that Usama has been providing various foundational series (like the
huge swap stuff) to establish this.

So Tl;DR - let's be incremental, cautious, and improve this damn codebase before
we even think of larger changes.

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo