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

[Nadia Chambers <nadia.yvette.chambers@ik.me>]

On Thu, Feb 19, 2026 at 04:39:34PM +0100, David Hildenbrand (Arm) wrote:
>> When discussing per-process page sizes with Ryan and Dev, I mentioned that
>> having a larger emulated page size could be interesting for other
>> architectures as well.
>> That is, we would emulate a 64K page size on Intel for user space as well,
>> but let the OS work with 4K pages.
>> We'd only allocate+map large folios into user space + pagecache, but still
>> allow for page tables etc. to not waste memory.
>> So "most" of your allocations in the system would actually be at least 64k,
>> reducing zone lock contention etc.

Am Do, Feb 19, 2026 um 15:54:56 +0000, Kiryl Shutsemau schrieb:
> I am not convinced emulation would help zone lock contention. I expect
> contention to be higher if page allocator would see a mix of 4k and 64k
> requests. It sounds like constant split/merge under the lock.

Presumably because the higher-order allocations would lack the per-CPU
special-case handling for order 0? IIRC LLFree is lock-free at all
allocation orders, which would likely help the zone lock specifically.
I suppose there's a sense I'm hoping my memory isn't out-of-date, but I
would still be glad to see the improvement. Extending per-CPU freelists
to small nonzero orders z.B. 4 might also help zone locks to allocate
64 KiB case likely around as much as using PAGE_MMUSHIFT == 4.


On Thu, Feb 19, 2026 at 04:39:34PM +0100, David Hildenbrand (Arm) wrote:
>> It doesn't solve all the problems you wanted to tackle on your list (e.g.,
>> "struct page" overhead, which will be sorted out by memdescs).

Am Do, Feb 19, 2026 um 15:54:56 +0000, Kiryl Shutsemau schrieb:
> I don't think we can serve 1G pages out of buddy allocator with 4k
> order-0. And without it, I don't see how to get to a viable 1G THPs.

memdescs are too recent for me to know about, but there is a comment to
make about 1 GiB superpages: doubly exponential decays in availability
are going to overwhelm the effects of any reasonable valud of
PAGE_MMUSHIFT (your ilog(PG_SIZE/PTE_SIZE) which has no macro for it)
long before 1 GiB. Bumping a small constant off the grand total of
allocation orders isn't going to be an adequate strategy. ISTR Rik van
Riel had code going round to partition RAM into something akin to
pre-formed large z.B. 1 GiB superpages that's a far more meaningful
approach to 1 GiB superpages than reducing the allocation order for
1 GiB from 18 to 14 or 12. The double exponential makes orders above
maybe 2 or 3 require migration or compaction and there's a cut-off above
which you're going to need to be either be fresh off a virgin boot or to
do something slow bordering on swsusp-style mass eviction.

If memdescs, presumably from „memory descriptors“, are something like
memory extents, I wholeheartedly endorse moves to more extent-based or
extent-like memory management and can quibble about the details later.

You can make an argument that scaling may need to take special steps to
reduce the TLB entries for the smallest page sizes so they don't
outcompete the real datasets when they proliferate. But buddy allocating
(LLFree should be used instead) isn't going to be appreciably any better
at orders 14 (PAGE_MMUSHIFT == 4) or 12 (PAGE_MMUSHIFT == 6) than 18, as
with double exponential decays, it dropped to effectively zero onf.
vmtl. 5 or 6, and values of PAGE_SIZE much larger than 64-256 KiB would
likely require far more extensive efforts to address regressions driven
by bitblitting latency and internal fragmentation than simple things like
tail packing the page cache. If you're starting from an
MMUPAGE_SIZE/PTE_SIZE of 64 KiB z.B. ppc64, it only really changes the
story to cutting 14 to 10 or 8, but the net result of that with
PAGE_MMUSHIFT == 4 is a PAGE_SIZE of 1 MiB and for PAGE_MMUSHIFT == 6 of
4 MiB, which are clearly beyond the pale of what'll be tolerable for
insb. network latencies for high-performance scenarios.

There is a case where those handfuls of buddy bitmap orders makes a
difference: if you're trying to split the difference between z.B. the
MMUPAGE_SHIFT/ilog2(PTE_SIZE) and PMD_SHIFT. That's not reaching 1 GiB,
though. That's the only real benefit possible to offer in the trivial
case of the sparse page size spectrum. Dense page size spectra like
MIPS, LoongArch, RISC-V Svnapot, and Fujitsu M12 SPARC (I presume IA64
has sadly been completely discontinued at this point) are more of where
the benefits an argument can be made for are concentrated. In the
desperation of the sparse page size spectrum case z.B. x86 page size
growth increment / Sprungweite of 9 or some Apple M5 ARM systems' 11,
trimming orders off of it might be worth it even after something in the
vein of Rik's large superpage / „huge page“ -sized arenas, but with some
devoted to the first superpage size as that's too many orders off from
MMUPAGE_SIZE for naïve handling to work well.

To be clear, I am in favour of page clustering as per your pte_size,
Andrea's hard-page-size, my pgcl (not genuinely distinct from Hugh's
except via my being a far lesser coder than he), and Hugh's larpage.
My objection is that the rationale you've given isn't sustainable.


-- nyc