negative-order folios [LWN.net]

negative-order folios

Posted May 11, 2026 21:10 UTC (Mon) by willy (subscriber, #9762)
In reply to: negative-order folios by david.hildenbrand
Parent article: Providing 64KB base pages with 4KB kernels, two different ways

I think that was me. I talked about it a bit here:

https://lore.kernel.org/linux-mm/afIYFtL6KrBs38rT@casper....

but I wouldn't propose a negative order folio for a couple of reasons. I understand why our overworked scribe recorded it that way though; I'm sure my spoken words weren't perfectly clear.

First, folios are always >= PAGE_SIZE. As long as we want to be able to mmap things, they have to be PAGE_SIZE.

Second, allowing negative orders to the page allocator could never be more than a hack. That's just an unreasonable mental workload to any user. Instead, introduce a new interface that allows allocation of memory in units of 512 (rather than units of PAGE_SIZE) and reimplement alloc_page() as a wrapper around it.

to post comments

negative-order folios

Posted Jun 9, 2026 0:46 UTC (Tue) by nyc (guest, #91222) [Link]

Am I right that the linked message is describing an idea of eventually pervasively using descriptors for power-of-two -sized and -aligned memory regions? I do like this idea.

However, there is a notion of trading off some internal fragmentation to reduce the assembly ratio for the first superpage size for superpage size spectra with a wide gap between their base page size and their first superpage size. Using such an increased allocation unit (PAGE_SIZE) distinct from the TLB/MMU base page size (MMUPAGE_SIZE) also has a benefit of guaranteeing that smaller superpage size allocations won't fail from external fragmentation for architectures with dense superpage size spectra. There are also algorithms for maintaining ABI compatibility, likely originally due to Hugh Dickins, that beyond avoiding breaking ABI, also allow the allocation unit size to be compile-time configurable (or boot-time).

Depending on what people think the value of doing that is relative to the code to do it, it could be worth considering. I may even have something for it (hopefully Hugh will think I did his code and/or algorithms justice) that passes LTP on 16 architectures in qemu for PAGE_MMUSHIFT values of 0, 2, 4 and 6 (here PAGE_SHIFT == MMUPAGE_SHIFT + PAGE_MMUSHIFT).