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

[Nadia Chambers]

On Thu, Feb 19, 2026 at 03:08:51PM +0000, Kiryl Shutsemau wrote:
>> On x86, page tables are allocated from the buddy allocator and if PG_SIZE
>> is greater than 4 KB, we need a way to pack multiple page tables into a
>> single page. We could use the slab allocator for this, but it would
>> require relocating the page-table metadata out of struct page.

Am Do, Feb 19, 2026 um 17:47:22 +0000, Matthew Wilcox schrieb:
> Have you looked at the s390/ppc implementations (yes, they're different,
> no, that sucks)?  slab seems like the wrong approach to me.

Yes, they both required fair amounts of debugging. I don't remember what
went wrong in s390 early boot. ppc64 mm/slub.c item-within-page indices
ended up notably overflowing 16-bit counters. PA-RISC had some issues
surrounding a race with setup or teardown of I think accounting data
structures for some IO bus among other things. SPARC had an interesting
issue because its page order growth increment / Sprungweite was 3 where
the PAGE_MMUSHIFT increment used in testing was 2. Something odd
happened with SHMLBA on a bunch of architectures and I can't remember
whether there were hardware factors involved or if it was just include
and config messes leaking PAGE_SIZE.


Am Do, Feb 19, 2026 um 17:47:22 +0000, Matthew Wilcox schrieb:
> There's a third approach that I've never looked at which is to allocate
> the larger size, then just use it for N consecutive entries.

Strangely, I think the mechanical assistant did that for MIPS and few or
no others. It was simpler in various ways, but I didn't like the space or
locking overheads. Given the chance, I'll likely redo it bes. if I ever
get to demo MIPS' 1 KiB PageGrain extension running high performance
with a near-VAX minimum MMU/TLB mapping granularity.

My energies are more likely to be directed elsewhere if anywhere at all
from what you're telling me, though.


-- nyc