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

[Hillf Danton]

On Sun, 19 Jul 2026 02:51:08 +0200 Nadia Chambers wrote:
>On Thu, Feb 19, 2026 at 09:08:57AM -0800, Dave Hansen wrote:
>> So a 64k page cache eats ~5GB of extra memory for a kernel tree (well,
>> _my_ kernel tree). In other words, if you are looking for memory savings
>> on my laptop, you'll need ~300GB of RAM before 'struct page' overhead
>> overwhelms the page cache bloat from a single kernel tree.
>> The whole kernel obviously isn't in the page cache all at the same time.
>> The page cache across the system is also obviously different than a
>> kernel tree, but you get the point.
>> That's not to diminish how useful something like this might be,
>> especially for folks that are sensitive to 'struct page' overhead or
>> allocator performance.
>> But, it will mostly be getting better performance at the _cost_ of
>> consuming more RAM, not saving RAM.
>
> Given that you don't remember the project at all, I can assume the
> IBM-internal whitepaper where I described doing tail packing for small
> files in the pagecache as part of an array of strategies to mitigate
> internal fragmentation and latency issues expected to arise for large
> values of PAGE_MMUSHIFT is also forgotten. I wrote some things I thought
> worthwhile there and I was hoping you'd be able to at least corroborate
> the one-time, now-former existence of the thing and maybe some
> smatterings of its contents since it's no longer extant.
>
I dont think this discussion could make forward progress without clearly
drawing the rule of thumb that which page size is supposed to match what
RAM size, with the supported page size put aside now, because I dont know
why 128K page is needed in the xbc/yz environment.

	RAM size	page size
	32G		4K
	512G		128K
	4T		2M