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

[Gregory Price <gourry@gourry.net>]

On Mon, Jun 29, 2026 at 02:20:28PM +0200, David Hildenbrand (Arm) wrote:
> On 6/27/26 09:21, Qi Zheng wrote:
> > From: Qi Zheng <zhengqi.arch@bytedance.com>
> > 
> > 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 :)
> 

Without going into the nitty-gritty of the set here

  - Reserved   :  I care about whether this succeeeds.
  - Transparent:  I don't care. 

These things are mutually exclusive, so "Reserved THP" is confusing.

Maybe this makes more sense as mmap() MAP_ flags:
  - pre-allocates at the desired size
  - fails entirely if it fails

Since the intent is to *reserve* it anyway, it makes sense that this
would be a pre-populate directive regardless, so no lazy-faulting.

Then userland can ask for what it wants and if the kernel can't produce
it - allocation failed.

The underlying system can otherwise use whatever tricks it wants
(cma, reserved pages, etc) to get there from here, and all the swap
semantics otherwise live in normal interactions (mlock, madvise, etc).

Rik's work [0] is trying to move the allocator toward more reliable
hugepage allocation with the intent of making THPs more reliable in
general.  Maybe these things meet in the middle.

~Gregory

[0] https://lore.kernel.org/all/20260520150018.2491267-1-riel@surriel.com/