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

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

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.

Yeah agree, we're not doing this.

It's already a nightmare to deal with per-page anonexclusive vs. per-folio
pretty much everything else, and we shouldn't have allowed that to be a thing,
but now we have to live with it.

>
> I haven't seen the code yet, but I am certain that I will not like it.

If the code tries to implement anything that even resembles some sub-base-page
metadata then that's just not something that's going to land.

Handling VMA vs. folio state coherently is _already_ painful and difficult.

Piling on more complexity because we theoretically could feels rather along the
lines of 'let's just keep adding features and not worrying about where we end
up', which is I think a bit of an anti-pattern in the kernel in general.

>
> I'm happy to be proven wrong :)

Sure me also if I'm missing something, but what's discussed here is... worrying.

>
> --
> Cheers,
>
> David

Thanks, Lorenzo