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

[Barry Song <baohua@kernel.org>]

On Mon, Jun 29, 2026 at 8:20 PM David Hildenbrand (Arm)
<david@kernel.org> wrote:
[...]
> >
> > 2. Implementation
> > =================
> >
> > In 2024, Yu Zhao proposed a similar idea:
> >
> > Link: https://lore.kernel.org/all/20240229183436.4110845-2-yuzhao@google.com/
> >
> > The idea was to introduce two virt zones: ZONE_NOSPLIT and ZONE_NOMERGE to
> > guarantee the allocation success rate of THP, achieving an effect similar to
> > reservation. However, it seems there was no further progress, perhaps because of
> > reluctance to introduce more virt zones like ZONE_MOVABLE.
> >
> > This RFC wants to discuss another implementation:
> >
> > 1. Introduce a new migratetype: MIGRATE_RESERVED_THP.
> > 2. Introduce two new hugetlb-like kernel boot parameters: `thp_reserved_size`
> >    and `thp_reserved_nr`. When set, the required memory is marked as
> >    MIGRATE_RESERVED_THP and put back into the buddy allocator.
>
> I'm all for some mechanism to make runtime allocation of large chunks of memory
> easier, by adding a pool from where multiple consumers (THP, guest_memfd,
> hugetlb, whatever) can allocate memory.
>
> Call me very skeptical of getting the page allocator involved like this. (I hate it)

One thing we've been thinking about for a while is whether we can
introduce something at the pageblock level to let memory "remember"
which allocation order is preferred within that pageblock.

For example, if we ever allocate an order-0 page from pageblock 100,
that pageblock would later prefer order-0 allocations. Similarly, if
we allocate a large folio from pageblock 200, we would avoid using
pageblock 200 for order-0 allocations as long as there is still
memory available in pageblock 100 for order-0.

Since order-0 allocations are often the main source of fragmentation,
if we already have both pagecache and anonymous large folios, we may
care more about containing or quarantining order-0 allocations in
certain areas, rather than trying to maintain a large-folio pool or
similar strategy.

Chris’s de-fragmentation of swap slots[1] seems to be a big success
based on my observations, where he provides a similar memory-order
preference for swap clusters. There is no reservation mechanism, no
sysfs knob, and no need to split swap into two areas—everything
just works automatically.

I wonder if you would be interested in something similar at the
pageblock level. If so, I’d be happy to work on a prototype in
August. I’m completely booked in July.

[1] https://lore.kernel.org/all/20240730-swap-allocator-v5-0-cb9c148b9297@kernel.org/

Best Regards
Barry