Weird. AFAIK 4K and 64K were the common ARM64 page sizes, and 16K was the odd "think different" one that Apple uses. No mention of 16K in the Linux kernel docs:
AMD also switched to 16k(4 x 4K) down from 8 in Zen1 for there PTE Coalescing system that is effectively run length like compression of page table entries with sequential addresses in to one TLB slot.
I can understand the desire for google to want devs to recompile their apps, but I don't see the need to dump old apps from the app store... who cares if an old app that works wastes 12k if it only needs a single 4k page?
I used to work closely with the Android team at Unity, and in my experience, shifting large native codebases to a new page size often uncovers subtle runtime assumptions beyond just replacing hardcoded constants like PAGE_SIZE. I’m optimistic Google’s tooling will help a lot, but interested about how effectively it catches these more nuanced compatibility issues like custom allocators or memory pooling tuned for 4K boundaries.
Someone I collaborate with has been having all sorts of fun with a 4k->64k page transition for stuff running on Arm. Among some of the fun has been discovering memory leaks that really weren't noticeable or a big deal at 4k, but now that the page is 16x larger, suddenly becomes noticeable and can even cause problems.
> Starting November 1st, 2025, all new apps and app updates that use native C/C++ code targeting Android 15+ devices submitted to Google Play must support 16 KB page sizes.
I realize that most apps wouldn’t need to make changes and that a recompilation would suffice, but is this time frame enough for the apps that do need code changes?
If you're making the migration at all, you really ought to be going for fully variable page sizes, otherwise 5 years from now there'll be a 64K page size CPU and suddenly everyone has to recompile everything again and there is another compatibility wall...
4 KiB page sizes have been used since the 1960's. More memory doesn't necessarily mean that larger pages are beneficial. Maybe 16 KiB is better for Android? Maybe. There really is no clear consensus on what the optimal page size for modern architectures should be.
From the experience implementing 64K page sizes on aarch64 in Fedora & RHEL, this is not going to be a simple transition. All sorts of things will break in subtle, strange and interesting ways. Good luck to the Android team :-)
This is dumb. The abstraction is at the wrong level.
Applications should assume the page size is 1 byte. One should be able to map, protect, etc memory ranges down to byte granularity - which is the granularity of everything else in computers. One fewer thing for programmers to worry about. History has shown that performance hacks with ongoing complexity tend not to survive (eg. interlaced video).
At the hardware level, rather than picking a certain number of bits of the address as the page size, you have multiple page tables, and multiple TLB caches - eg. one for 1 megabyte pages, one for 4 kilobyte pages, and one for individual byte pages. The hardware will simultaneously check all the tables (parallelism is cheap in hardware!).
The benefit of this is that, assuming the vast majority of bytes in a process address space are made of large mappings, you can fit far more mappings in the (divided up) TLB - which results in better performance too, whilst still being able to do precise byte-level protections.
The OS is the only place there is complexity - which has to find a way to fit the mappings the application wants into what the hardware can do (ie. 123456 bytes might become 30 4-kilobyte pages and 576 byte pages.).
Transistors aren't free (as in power consumptions, thermal etc), and wasting them on implementing 1 byte granularity TLBs would probably be a hard sell, even if assuming everything can indeed be done in parallel.
17 comments
[ 3.0 ms ] story [ 47.0 ms ] threadhttps://www.kernel.org/doc/html/next/arm64/memory.html
I realize that most apps wouldn’t need to make changes and that a recompilation would suffice, but is this time frame enough for the apps that do need code changes?
What typically tends to break when changing it?
Applications should assume the page size is 1 byte. One should be able to map, protect, etc memory ranges down to byte granularity - which is the granularity of everything else in computers. One fewer thing for programmers to worry about. History has shown that performance hacks with ongoing complexity tend not to survive (eg. interlaced video).
At the hardware level, rather than picking a certain number of bits of the address as the page size, you have multiple page tables, and multiple TLB caches - eg. one for 1 megabyte pages, one for 4 kilobyte pages, and one for individual byte pages. The hardware will simultaneously check all the tables (parallelism is cheap in hardware!).
The benefit of this is that, assuming the vast majority of bytes in a process address space are made of large mappings, you can fit far more mappings in the (divided up) TLB - which results in better performance too, whilst still being able to do precise byte-level protections.
The OS is the only place there is complexity - which has to find a way to fit the mappings the application wants into what the hardware can do (ie. 123456 bytes might become 30 4-kilobyte pages and 576 byte pages.).
information design is my passion