Re: [LSF/MM/BPF TOPIC] 64k (or 16k) base page size on x86

[Kiryl Shutsemau]

On Mon, Feb 23, 2026 at 04:31:56PM +0100, David Hildenbrand (Arm) wrote:
> On 2/23/26 16:14, Dave Hansen wrote:
> > On 2/23/26 03:27, David Hildenbrand (Arm) wrote:
> > ...
> > > > BTW, x86-64 SysV ABI allows for 64k page size:
> > > > 
> > > >      Systems are permitted to use any power-of-two page size between
> > > >      4KB and 64KB, inclusive.
> > > > 
> > > > But it doesn't work in practice.
> > > 
> > > Even in well controlled environments you would run in a hyperscaler?
> > 
> > I think what Kirill is trying to say is that "it breaks userspace". ;)
> 
> Yes. Probably similar to Intel proposing an actual 64k page size. Expected.
> :)
> 
> > 
> > A hyperscaler (or other "embedded" environment) might be willing or able
> > to go fix up userspace breakage. I would suspect our high frequency
> > trading friends would be all over this if it shaved a microsecond off
> > their receive times.
> > 
> > The more important question is what it breaks and how badly it breaks
> > things. 5-level paging, for instance, broke some JITs that historically
> > used the new (>48) upper virtual address bits for metadata. The gains
> > from 5-level paging were big enough and the userspace breakage was
> > confined and fixable enough that 5-level paging was viable.
> > 
> > I'm not sure which side a larger base page side will fall on, though. Is
> > it going to be an out-of-tree hack that a few folks use, or will it be
> > more like 5-level paging and be good enough that it goes into mainline?
> 
> Just thinking about VMAs spanning partial pages makes me shiver. Or A
> single page spanning multiple VMAs.

Hate to break it to you, but we have it now upstream :P

THP can span multiple VMAs. And can be partially mapped.

The only new thing is that we allow this for order-0 page now. And you
cannot realistically recover wasted memory -- no deferred split.

> I haven't seen the code yet, but I am certain that I will not like it.
> 
> I'm happy to be proven wrong :)

I will do my best, but no promises :)

-- 
  Kiryl Shutsemau / Kirill A. Shutemov