Introducte Reserved THP

This RFC patchset introduces a new feature called "Reserved THP", and I'd like to open up a discussion on how to use this as a stepping stone toward unifying HugeTLB and THP (Transparent Huge Page).

Therefore, we are wondering if we can introduce "reserved THP", which is THP that can be reserved. It can be consumed through methods like madvise(), while normal memory allocation cannot consume it. This can achieve an effect similar to hugetlb. And because it is THP, it can relatively easily support swap features, which perfectly solves the above problem.

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.
3. Introduce a new madvise parameter: MADV_RESERVED_THP. Pages marked as MIGRATE_RESERVED_THP can only be consumed via madvise(MADV_RESERVED_THP). Other normal memory allocations cannot consume MIGRATE_RESERVED_THP memory.

This can achieve a reservation effect similar to HugeTLB and guarantee allocation success.

3. Future Plans
===============

3.1 Enhance swap-out and swap-in for large folios
-------------------------------------------------

Currently, For swap-out, THP_SWAP is supported, but it only tries to swap out the THP folio as a whole. It is still possible to be forced to split in some situations (e.g., fragmented swap space, memory.swap.max limits, etc). For swap-in, it is almost impossible to directly swap in the THP folio as a whole.

But for reserved THP, splitting is not allowed. We need to ensure that it remains a whole huge page during swap-out and swap-in, to achieve a function similar to hugetlb swap.

3.2 Integrate reserved THP into the common reclaim path
-------------------------------------------------------

Once swap-in and swap-out of huge pages can be supported without splitting, reserved THP can be integrated into the common reclaim path as a normal LRU folio for memory reclamation. This fills the gap of the hugetlb swap function.

3.4 Use reserved THP as a backend for hugetlbfs
-----------------------------------------------

This would allow existing hugetlb users or applications to seamlessly switch to reserved THP.

3.5 Add 1GB page support to reserved THP
----------------------------------------

Historically, there have been several attempts to add 1GB huge page support to THP:

1. https://lore.kernel.org/linux-mm/[email protected]/
2. https://lore.kernel.org/linux-mm/[email protected]/

Adding 1GB huge page support for reserved THP would be relatively simpler compared to regular THP.

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.

Quoted 3 lines · Qi Zheng

This RFC patchset introduces a new feature called "Reserved THP", and I'd like to open up a discussion on how to use this as a stepping stone toward unifying HugeTLB and THP (Transparent Huge Page).

I'm really happy you're looking into this. I'm not terribly familiar with the page allocator code, so I don't have any comments on the patches themselves, but I do have a few on your approach.

Quoted 6 lines

Therefore, we are wondering if we can introduce "reserved THP", which is THP that can be reserved. It can be consumed through methods like madvise(), while normal memory allocation cannot consume it. This can achieve an effect similar to hugetlb. And because it is THP, it can relatively easily support swap features, which perfectly solves the above problem.

As I understand it, hugetlbfs reserves on mmap().

Quoted 11 lines

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.
3. Introduce a new madvise parameter: MADV_RESERVED_THP. Pages marked as MIGRATE_RESERVED_THP can only be consumed via madvise(MADV_RESERVED_THP). Other normal memory allocations cannot consume MIGRATE_RESERVED_THP memory.

Quoted 2 lines

This can achieve a reservation effect similar to HugeTLB and guarantee allocation success.

I think this is an interesting approach. I don't think it should be too hard to migrate existing hugetlbfs users to it.

Quoted 12 lines

3. Future Plans
===============

3.1 Enhance swap-out and swap-in for large folios
-------------------------------------------------

Currently, For swap-out, THP_SWAP is supported, but it only tries to swap out the THP folio as a whole. It is still possible to be forced to split in some situations (e.g., fragmented swap space, memory.swap.max limits, etc). For swap-in, it is almost impossible to directly swap in the THP folio as a whole.

Quoted 3 lines

But for reserved THP, splitting is not allowed. We need to ensure that it remains a whole huge page during swap-out and swap-in, to achieve a function similar to hugetlb swap.

So I think the current restriction is something that needs to be fixed anyway. It doesn't actually make sense that a folio must be written out contiguously; filesystems do not have this restriction. I understand

why swap currently has this limitation, but I'm hoping it gets removed at some point. I'm not sure if the people working on swap right now intend to fix this. They're already on the cc, so I hope they chime in.

Quoted 7 lines

3.2 Integrate reserved THP into the common reclaim path
-------------------------------------------------------

Once swap-in and swap-out of huge pages can be supported without splitting, reserved THP can be integrated into the common reclaim path as a normal LRU folio for memory reclamation. This fills the gap of the hugetlb swap function.

Hm. Then what does "reserved THP" mean if they can be swapped out?

Quoted 6 lines

3.4 Use reserved THP as a backend for hugetlbfs
-----------------------------------------------

This would allow existing hugetlb users or applications to seamlessly switch to reserved THP.

If this is the end goal, then I think introducing new command line options is probably the wrong approach right now. Instead, "reserved THPs" should be allocated from the same pool as hugetlb reserve. That way we're not jerking sysadmins around.

Quoted 7 lines

3.5 Add 1GB page support to reserved THP
----------------------------------------

Historically, there have been several attempts to add 1GB huge page support to THP:

Quoted 5 lines

1. https://lore.kernel.org/linux-mm/[email protected]/
2. https://lore.kernel.org/linux-mm/[email protected]/

Adding 1GB huge page support for reserved THP would be relatively simpler compared to regular THP.

Well. Maybe? What happens if we mmap() 16GiB,

madvise(USE_RESERVED_THPS) and then munmap() the first 4KiB of it?

Quoted 7 lines

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.

We also need mshare to land ... but yes, eventually removing hugetlbfs

is my hope.

From: Qi Zheng <[email protected]>

Hi all,

This RFC patchset introduces a new feature called "Reserved THP", and I'd like to open up a discussion on how to use this as a stepping stone toward unifying HugeTLB and THP (Transparent Huge Page).

1. Background
=============

Currently, two huge page solutions co-exist in the kernel:

1. HugeTLB: Supports reservation, guaranteeing successful allocation within the reserved pool. However, it does not support features like swap. And it is a relatively independent subsystem.
2. THP: Does not support reservation and may fail to allocate and fallback to small pages when system memory is fragmented, but it is more tightly integrated with mm core and supports features like swap.

Both have their pros and cons. However, in one of our internal scenarios, it seems we need to combine the features of both to meet the requirements.

In our internal scenario, a user process needs to reserve double the amount of Hugetlb memory due to hot-upgrade requirements. For example, if the process needs 16GB of Hugetlb, an additional 16GB is required during the hot-upgrade to satisfy memory allocations. After the upgrade, the old process exits and releases the 16GB of HugeTLB. Therefore, in most cases, the extra 16GB of HugeTLB is wasted.

A straightforward idea is to use the Hugetlb CMA feature, reserving a total of 32GB of hugetlb_cma. During normal operation, 16GB is consumed, and the remaining 16GB can be used by other processes. During hot-upgrade, we could try to migrate the memory used by other processes to allocate the required extra 16GB of Hugetlb. This might work, but it still requires reserving 32GB of memory.

We also found that during the hot upgrade, about 10GB of the old process's hugetlb is actually cold memory, which could theoretically be reclaimed. In extreme cases, we could reserve only 22GB of memory and reclaim the remaining 10GB during the hot upgrade. But unfortunately, hugetlb currently does not support swap, and supporting it seems quite difficult.

Therefore, we are wondering if we can introduce "reserved THP", which is THP that can be reserved. It can be consumed through methods like madvise(), while normal memory allocation cannot consume it.

This can achieve an effect similar
to hugetlb. And because it is THP, it can relatively easily support swap features, which perfectly solves the above problem.

Additionally, in 2024 (or possibly earlier), there have been discussions about the possibility of unifying Hugetlb and THP:

Link https://lwn.net/Articles/974491/

After all, hugetlb's management is relatively independent and requires too much special handling in mm core. The introduction of reserved THP might be an opportunity. In the future, reserved THP could be enhanced to support various hugetlb features, such as acting as a backend for hugetlbfs. When reserved THP can completely replace HugeTLB, HugeTLB could be entirely removed, and reserved THP would just become a feature of THP.

2. Implementation
=================

In 2024, Yu Zhao proposed a similar idea:

Link https://lore.kernel.org/all/[email protected]/ open here

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.

3. Introduce a new madvise parameter: MADV_RESERVED_THP. Pages marked as MIGRATE_RESERVED_THP can only be consumed via madvise(MADV_RESERVED_THP). Other normal memory allocations cannot consume MIGRATE_RESERVED_THP memory.

This can achieve a reservation effect similar to HugeTLB and guarantee allocation success.

3. Future Plans
===============

3.1 Enhance swap-out and swap-in for large folios
-------------------------------------------------

Currently, For swap-out, THP_SWAP is supported, but it only tries to swap out the THP folio as a whole. It is still possible to be forced to split in some situations (e.g., fragmented swap space, memory.swap.max limits, etc). For swap-in, it is almost impossible to directly swap in the THP folio as a whole.

But for reserved THP, splitting is not allowed. We need to ensure that it remains a whole huge page during swap-out and swap-in, to achieve a function similar to hugetlb swap.

3.2 Integrate reserved THP into the common reclaim path
-------------------------------------------------------

Once swap-in and swap-out of huge pages can be supported without splitting, reserved THP can be integrated into the common reclaim path as a normal LRU folio for memory reclamation. This fills the gap of the hugetlb swap function.

3.3 Use reserved THP as a backend for shmem/tmpfs
-------------------------------------------------

This would allow shared or file-like usage to utilize reserved THP.

3.4 Use reserved THP as a backend for hugetlbfs
-----------------------------------------------

This would allow existing hugetlb users or applications to seamlessly switch to reserved THP.

3.5 Add 1GB page support to reserved THP
----------------------------------------

Historically, there have been several attempts to add 1GB huge page support to THP:

1. https://lore.kernel.org/linux-mm/[email protected]/
2. https://lore.kernel.org/linux-mm/[email protected]/

Adding 1GB huge page support for reserved THP would be relatively simpler compared to regular THP.

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.

Quoted 5 lines · Qi Zheng

From: Qi Zheng <[email protected]>

Therefore, we are wondering if we can introduce "reserved THP", which is THP that can be reserved. It can be consumed through methods like madvise(), while normal memory allocation cannot consume it.

madvise(). Gah. No :)

Quoted 13 lines

2. Implementation
=================

In 2024, Yu Zhao proposed a similar idea:

Link https://lore.kernel.org/all/[email protected]/ open here

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.

Quoted 6 lines

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)

On Mon, Jun 29, 2026 at 8:20 PM David Hildenbrand (Arm) <[email protected]> wrote:
[...]

Quoted 20 lines

Quoted 13 lines

2. Implementation
=================

In 2024, Yu Zhao proposed a similar idea:

Link https://lore.kernel.org/all/[email protected]/ open here

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.

Quoted 6 lines

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.

Quoted 5 lines

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/[email protected]/

Quoted 39 lines · Barry Song

On Mon, Jun 29, 2026 at 8:20 PM David Hildenbrand (Arm) <[email protected]> wrote:
[...]

Quoted 20 lines

Quoted 13 lines

2. Implementation
=================

In 2024, Yu Zhao proposed a similar idea:

Link https://lore.kernel.org/all/[email protected]/ open here

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.

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 5 lines

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.

Aren't unmovable pages causing fragmentation? For movable pages, regardless of their orders, they can always be migrated if no additional pin is present.

If we use per-order pageblocks, how to use pageblocks with rarely used orders? Allowing lower order to fallback to higher order pageblocks?

Quoted 8 lines

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.

Quoted 6 lines

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/[email protected]/

I feel that swap and page allocation have a fundamental distintion, where swap slots are not movable, but pages can. Memory compaction can move pages around to make space for high order allocations, but does swap support something similar? How will page mobility work in this swap slot defragmentation world?

In addition, when swap space is full, or only order-0 swap slots are available but higher order folios want to be swapped out, folio swap might simply stop (except splitting folios to fill the order-0 slots). But for page allocation, some pages can be reclaimed/swapped to make space and this adds complexity.

Quoted 4 lines · Qi Zheng

From: Qi Zheng <[email protected]>

Hi all,

Hi,

Quoted 39 lines

This RFC patchset introduces a new feature called "Reserved THP", and I'd like to open up a discussion on how to use this as a stepping stone toward unifying HugeTLB and THP (Transparent Huge Page).

1. Background
=============

Currently, two huge page solutions co-exist in the kernel:

1. HugeTLB: Supports reservation, guaranteeing successful allocation within the reserved pool. However, it does not support features like swap. And it is a relatively independent subsystem.
2. THP: Does not support reservation and may fail to allocate and fallback to small pages when system memory is fragmented, but it is more tightly integrated with mm core and supports features like swap.

Both have their pros and cons. However, in one of our internal scenarios, it seems we need to combine the features of both to meet the requirements.

In our internal scenario, a user process needs to reserve double the amount of Hugetlb memory due to hot-upgrade requirements. For example, if the process needs 16GB of Hugetlb, an additional 16GB is required during the hot-upgrade to satisfy memory allocations. After the upgrade, the old process exits and releases the 16GB of HugeTLB. Therefore, in most cases, the extra 16GB of HugeTLB is wasted.

A straightforward idea is to use the Hugetlb CMA feature, reserving a total of 32GB of hugetlb_cma. During normal operation, 16GB is consumed, and the remaining 16GB can be used by other processes. During hot-upgrade, we could try to migrate the memory used by other processes to allocate the required extra 16GB of Hugetlb. This might work, but it still requires reserving 32GB of memory.

We also found that during the hot upgrade, about 10GB of the old process's hugetlb is actually cold memory, which could theoretically be reclaimed. In extreme cases, we could reserve only 22GB of memory and reclaim the remaining 10GB during the hot upgrade. But unfortunately, hugetlb currently does not support swap, and supporting it seems quite difficult.

Quoted 3 lines

Therefore, we are wondering if we can introduce "reserved THP", which is THP that can be reserved. It can be consumed through methods like madvise(), while normal memory allocation cannot consume it.

madvise(). Gah. No :)

Quoted 3 lines

This can achieve an effect similar
to hugetlb. And because it is THP, it can relatively easily support swap features, which perfectly solves the above problem.

No, this is the wrong approach. We really shouldn't be making the same mistake hugetlb did and support reserving of non-filebacked memory (IOW anonymous memory).

And even for files, the hugetlb mechanism is an absolute trainwreck, because it's not NUMA aware.

This really needs some proper thought.

Quoted 28 lines

Additionally, in 2024 (or possibly earlier), there have been discussions about the possibility of unifying Hugetlb and THP:

Link https://lwn.net/Articles/974491/

After all, hugetlb's management is relatively independent and requires too much special handling in mm core. The introduction of reserved THP might be an opportunity. In the future, reserved THP could be enhanced to support various hugetlb features, such as acting as a backend for hugetlbfs. When reserved THP can completely replace HugeTLB, HugeTLB could be entirely removed, and reserved THP would just become a feature of THP.

2. Implementation
=================

In 2024, Yu Zhao proposed a similar idea:

Link https://lore.kernel.org/all/[email protected]/ open here

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:

Quoted 4 lines

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)

Quoted 3 lines

3. Introduce a new madvise parameter: MADV_RESERVED_THP. Pages marked as MIGRATE_RESERVED_THP can only be consumed via madvise(MADV_RESERVED_THP). Other normal memory allocations cannot consume MIGRATE_RESERVED_THP memory.

Definitely no.

Quoted 23 lines

This can achieve a reservation effect similar to HugeTLB and guarantee allocation success.

3. Future Plans
===============

3.1 Enhance swap-out and swap-in for large folios
-------------------------------------------------

Currently, For swap-out, THP_SWAP is supported, but it only tries to swap out the THP folio as a whole. It is still possible to be forced to split in some situations (e.g., fragmented swap space, memory.swap.max limits, etc). For swap-in, it is almost impossible to directly swap in the THP folio as a whole.

But for reserved THP, splitting is not allowed. We need to ensure that it remains a whole huge page during swap-out and swap-in, to achieve a function similar to hugetlb swap.

3.2 Integrate reserved THP into the common reclaim path
-------------------------------------------------------

Quoted 9 lines

Once swap-in and swap-out of huge pages can be supported without splitting, reserved THP can be integrated into the common reclaim path as a normal LRU folio for memory reclamation. This fills the gap of the hugetlb swap function.

3.3 Use reserved THP as a backend for shmem/tmpfs
-------------------------------------------------

This would allow shared or file-like usage to utilize reserved THP.

Really, any kind of reservation should be file-centric and have some level of control.

And soon the question would pop up "but how can we control this inside memcgs".

This all needs some thought.

Quoted 5 lines

3.4 Use reserved THP as a backend for hugetlbfs
-----------------------------------------------

This would allow existing hugetlb users or applications to seamlessly switch to reserved THP.

You are really talking about a memory pool that can be used by different consumers.

I raised that in the past in the context of guest_memfd, whereby the short-term plan is to take pages from hugetlb's pool, when really there should be a global pool that can be consumed by various consumers.

A lot of questions around that.

Quoted 4 lines

3.5 Add 1GB page support to reserved THP
----------------------------------------

Quoted 8 lines

Historically, there have been several attempts to add 1GB huge page support to THP:

1. https://lore.kernel.org/linux-mm/[email protected]/
2. https://lore.kernel.org/linux-mm/[email protected]/

Adding 1GB huge page support for reserved THP would be relatively simpler compared to regular THP.

And that's what I told Usama: start with 1 GiB THP support for shmem/tmpfs, and make it configurable.

How we would add a reservation mechanism is a good question. Because hugetlb reservation is a broken concept. And anything that's not NUMA or memcg aware will be a broken concept I'm afraid.

Quoted 4 lines

3.6 Remove Hugetlb
------------------

Quoted 3 lines

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.

Quoted 57 lines · David Hildenbrand (Arm)

Quoted 4 lines · Qi Zheng

From: Qi Zheng <[email protected]>

Hi all,

Hi,

Quoted 39 lines

This RFC patchset introduces a new feature called "Reserved THP", and I'd like to open up a discussion on how to use this as a stepping stone toward unifying HugeTLB and THP (Transparent Huge Page).

1. Background
=============

Currently, two huge page solutions co-exist in the kernel:

1. HugeTLB: Supports reservation, guaranteeing successful allocation within the reserved pool. However, it does not support features like swap. And it is a relatively independent subsystem.
2. THP: Does not support reservation and may fail to allocate and fallback to small pages when system memory is fragmented, but it is more tightly integrated with mm core and supports features like swap.

Both have their pros and cons. However, in one of our internal scenarios, it seems we need to combine the features of both to meet the requirements.

In our internal scenario, a user process needs to reserve double the amount of Hugetlb memory due to hot-upgrade requirements. For example, if the process needs 16GB of Hugetlb, an additional 16GB is required during the hot-upgrade to satisfy memory allocations. After the upgrade, the old process exits and releases the 16GB of HugeTLB. Therefore, in most cases, the extra 16GB of HugeTLB is wasted.

A straightforward idea is to use the Hugetlb CMA feature, reserving a total of 32GB of hugetlb_cma. During normal operation, 16GB is consumed, and the remaining 16GB can be used by other processes. During hot-upgrade, we could try to migrate the memory used by other processes to allocate the required extra 16GB of Hugetlb. This might work, but it still requires reserving 32GB of memory.

We also found that during the hot upgrade, about 10GB of the old process's hugetlb is actually cold memory, which could theoretically be reclaimed. In extreme cases, we could reserve only 22GB of memory and reclaim the remaining 10GB during the hot upgrade. But unfortunately, hugetlb currently does not support swap, and supporting it seems quite difficult.

Quoted 3 lines

Therefore, we are wondering if we can introduce "reserved THP", which is THP that can be reserved. It can be consumed through methods like madvise(), while normal memory allocation cannot consume it.

madvise(). Gah. No :)

Quoted 3 lines

This can achieve an effect similar
to hugetlb. And because it is THP, it can relatively easily support swap features, which perfectly solves the above problem.

Quoted 7 lines

No, this is the wrong approach. We really shouldn't be making the same mistake hugetlb did and support reserving of non-filebacked memory (IOW anonymous memory).

And even for files, the hugetlb mechanism is an absolute trainwreck, because it's not NUMA aware.

This really needs some proper thought.

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?

Quoted 33 lines

Quoted 32 lines

Additionally, in 2024 (or possibly earlier), there have been discussions about the possibility of unifying Hugetlb and THP:

Link https://lwn.net/Articles/974491/

After all, hugetlb's management is relatively independent and requires too much special handling in mm core. The introduction of reserved THP might be an opportunity. In the future, reserved THP could be enhanced to support various hugetlb features, such as acting as a backend for hugetlbfs. When reserved THP can completely replace HugeTLB, HugeTLB could be entirely removed, and reserved THP would just become a feature of THP.

2. Implementation
=================

In 2024, Yu Zhao proposed a similar idea:

Link https://lore.kernel.org/all/[email protected]/ open here

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.

Quoted 3 lines

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.

I agree with this one. We do not want to invent different free memory reservation mechanisms for each possible consumer. A shared reservation mechanism with different reservation and allocation policies is better.

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?

Quoted 7 lines

Quoted 6 lines

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.

Quoted 4 lines

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.

... digging through old mail.

Quoted 9 lines

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.

[...]

Quoted 10 lines

Quoted 10 lines

Quoted 6 lines

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.

Quoted 5 lines

Quoted 1 line

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.

--
Cheers,

David