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

[Matthew Wilcox <willy@infradead.org>]

On Tue, Feb 24, 2026 at 02:08:26PM -0500, Zi Yan wrote:
> On 24 Feb 2026, at 14:03, Johannes Weiner wrote:
> > On Thu, Feb 19, 2026 at 03:53:35PM +0000, Usama Arif wrote:
> >> Why 1G THP over hugetlbfs?
> >> ==========================
> >
> > I know this isn't your intention, but one interesting aspect of
> > supporting PUD mapped folios natively is that it could open the door
> > to simplifying hugetlb as well.
> >
> > We currently have all kinds of huge_vma checks scattered over the page
> > table code, and entirely parallel paths for unmapping etc. With native
> > PUD mappings, this could allow pushing the special casing out of the
> > virtual memory layer and into where we deal with the page objects.
> >
> > You might be able to take it as far as the only thing left of hugetlb
> > is the reservation pool. Such that a naive application does mmap() as
> > per usual, and it comes down to a separate allocation policy how the
> > backing pages are served (buddy, CMA, boot-time reservations, ...)
> >
> > Approaching it this way could help separate out the discussion on code
> > impact and tech debt of PUD mappings, from the allocation technique
> > question, which in itself is a fairly large topic.
> 
> I agree with this 100%. Adding 1GB folio support first, we then can think
> about what other THP features, e.g., split, migration, PMD/PTE mapping, are
> really needed and add them one by one. It is also going to be a good way
> of retiring hugetlb special code.

But this hasn't happened yet for PMD-sized hugetlb, and there's no need
to wait for PUD-sized THP to start this process.  I don't think that
introducing PUD-sized THP will actually motivate anyone to do this work.

I think we have four main things that hugetlb still offers:

 - Reserved pool (mentioned above) which we don't yet have a THP
   replacement for
 - shared page tables.  mshare() is the replacement here, and that
   project is moving along nicely.
 - Being able to allocate gigantic folios.  This is also progressing.
 - Guaranteeing that you don't get a fallback; you either get memory in
   the size you asked for, or you fail.

Every time this comes up, I offer the pagewalk code as an egregious
example of where we force every user to know "oh, hugetlb is special".
Getting rid of mm_walk_ops->hugetlb_entry() would be a great improvement.

People always look at the fault handler first and say "Ah, this is
an obvious hugetlb-is-special case I can get rid of", but honestly
it's not that painful to keep around and doesn't affect anyone else.
mm_walk_ops affects everybody who walks page tables.