Re: [LSF/MM/BPF TOPIC] Beyond 2MB: Why Terabyte-Scale Machines Need 1GB Transparent Huge Pages

[Johannes Weiner <hannes@cmpxchg.org>]

On Thu, Feb 19, 2026 at 05:00:19PM +0100, David Hildenbrand (Arm) wrote:
> 
> > 
> > I see 1G THPs being opportunistically used ideally at the start of the application
> > or by the allocator (jemalloc/tcmalloc) when there is plenty of free memory
> > available and a greater chance of getting 1G THPs.
> > 
> > Splitting strategy
> > ==================
> > 
> > When PUD THP must be break -- for COW after fork, partial munmap, mprotect on
> > a subregion, or reclaim -- it splits directly from PUD to PTE level, converting
> > 1 PUD entry into 262,144 PTE entries. The ideal solution would be to split to
> > PMDs and only the necessary PMDs to PTEs. This is something that would hopefully
> > be possible with Davids proposal [3].
> 
> There once was this proposal where we would, instead of splitting a THP, 
> migrate all memory away instead. That means, instead of splitting the 1 
> GiB THP, you would instead return it to the page allocator where 
> somebody else could use it.

With TLB coalescing, there is benefit in preserving contiguity. If you
lop off the last 4k of a 2M-backed range, a split still gives you 511
contiguously mapped pfns that can be coalesced.

It would be unfortunate to lose that for pure virtual memory splits,
while there is no demand or no shortage of huge pages. But it might be
possible to do this lazily, e.g. when somebody has trouble getting a
larger page, scan the deferred split lists for candidates to migrate.