6 ms·
Transition to using 16 KB page sizes for Android apps and games
- userbinator 1y agoWeird. 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: https://www.kernel.org/doc/html/next/arm64/memory.html https://www.kernel.org/doc/html/next/arm64/memory.html
- jeffbee 1y ago16K is the weird one in practice, but ARM says they are implementation-defined. https://developer.arm.com/documentation/101811/0104/Translation-granule?lang=en https://developer.arm.com/documentation/101811/0104/Translat...
- ryao 1y agoThe 64-bit kernel shipped for the Raspberry Pi 5 uses 16KB pages.
- tux3 1y ago64K starts to be a little too wasteful. It is a small performance gain as you'd expect, but less granularity means significantly more wasted memory On a phone with limited RAM, this starts to be a bad tradeoff quickly. 16K is a reasonable jump from the venerable 4K page size.
- fsfod 1y agoAMD 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.
- surajrmal 1y agoiPhone uses 16KiB pages as well.
- nubinetwork 1y agoI 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?
- ryao 1y agoI am not familiar with Android, but Linux ELF binaries that specify 4KB alignment will not work on systems with 16KB page sizes, since the ELF interpreter will refuse to load them. This hit me recently when trying to run a 32-bit binary on a Linux ARM system that had 16KB size pages, since the 32-bit OpenSSL libraries specified 4KB alignment. Presumably, this was done for maximizing entropy available to ASLR, but it breaks the binaries when the page size increases. In any case, I assume that there is something similar affecting Android.
- dwattttt 1y agoPage size impacts page permissions; it's not a matter of wasting 12k, it's that with 4kb pages you're allowed to have a consecutive 8kb region with different permissions. 16kb pages can't do that without segfaulting every time memory is used "wrong", and trying to fix that up transparently would be a nightmare.
- yjftsjthsd-h 1y ago> 16kb pages can't do that without segfaulting every time memory is used "wrong", and trying to fix that up transparently would be a nightmare. I would natively imagine the kernel could trap that and remap on the fly, at the tiny cost of murdering performance. Is that untrue, or is the perf so bad that it's not worth it?
- plorkyeran 1y agoAnything which involves the kernel tracking permissions at 4k granularity despite using larger pages is just going to be worse in every way than using 4k pages.
- mkw5053 1y agoI 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.
- HPsquared 1y agoCould they find those by setting page size to some absurdly large value like 1MB?
- majke 1y agoA lot of software wont work if you do that. Many jits and memory allocators have opinions on page size. Also tagged pointers are very common.
- rwmj 1y agoAlso quite a lot of kernel drivers allocate whole pages (sometimes the device being driven requires it).
- bigstrat2003 1y agoThis just provides yet another example of why tagged pointers are a terrible idea and shouldn't be used. Someday, more of the address space will get used and your software will break.
- vient 1y agoMemory page size should be transparent for tagged pointers (any pointers, really), I don't see how they can be affected. You have an object at address 0xAB0BA, does the size of underlying page matter?
- danudey 1y ago
- AnonC 1y ago> 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?
- extraduder_ire 1y agoThey've mentioned this requirement before, last hn post I see is from early may. They only added support in android 15, in august 2024. https://android-developers.googleblog.com/2024/08/adding-16-kb-page-size-to-android.html https://android-developers.googleblog.com/2024/08/adding-16-... I don't know what "targetting Android 15+" means specifically. Does that include anything with a lower API level?
- jlokier 1y ago> I don't know what "targetting Android 15+" means specifically. Does that include anything with a lower API level? - On Android, apps are built with targetSdkVersion set to the API version you're app is compiled for and tested against, but you cam set a lower minSdkVersion to the lowest device API version your app will run on. - On devices with API level newer than targetSdkVersion, the OS looks at your app's targetSdkVersion and disables newer behaviours than your app is targetting. So the app should run well on newer devices. - On devices with API level older than targetSdkVersion, but newer than (or same as) minSdkVersion, your own app is responsible for detecting missing APIs before trying to use them, and adapting itself to the older environment. - On devices with API level older than minSdkVersion, your app will not be run. This ensures the user gets a clear failure, rather than unpredictable crashes or unexpected behaviour due to missing APIs the app tries to call. So, in principle, it's possible to build an app which targets the most recent Android 15, while being capable of running on all versions of Android back to version 1. Apps linked for 16 kiB page-alignment should run on older devices that use 4 kiB pages too. The Google Play Store enforces that targetSdkVersion is fairly close to the latest Android version. But it doesn't place requirements on minSdkVersion.
- 1y ago
- nephanth 1y agoFrom my noobish standpoint, it feels like most code shounldn't care what the page size is? Why does it need te be recompiled? What typically tends to break when changing it?
- kevingadd 1y agoOff the top of my head: If you rely on being able to do things like mark a range of memory as read-only or executable, you now have to care about page sizes. If your code is still assuming 4KB pages you may try to change the protection of a subset of a page and it will either fail to do what you want or change way too much. In both cases weird failures will result. It also can have performance consequences. For example, if before you were making a lot of 3.5KB allocations using mmap, the wastage involved in allocating a 4KB page for each one might not have been too bad. But now those 3.5KB allocations will eat a whole 16KB page, making your app waste a lot of memory. Ideally most applications aren't using mmap directly for this sort of thing though. I could imagine it making life harder for the authors of JIT compilers. Some algorithms also take advantage of the page size to do addressing tricks. For example, if you know your page size is 4KB, the addresses '3' and '4091' both can be known to have the same protection flags applied (R/W/X) and be the same kind of memory (mmap'd file on disk, shared memory segment, mapped memory from a GPU, etc.) This would allow any tables tracking information like that to only have 4KB granularity and make the tables much smaller. So that sort of trick needs to know the page size too.
- leidenfrost 1y agoTypically low level code and some manual fiddling with memory by asuming page size. Everything's ok until some obscure library suddenly segfaults without any error
- okanat 1y agoBecause the final ELF binary is linked to contain page aligned segments. Segments define how should the binary be loaded into memory and what permissions they require. If you have a 4KB segment that is marked Read-Write followed immediately by a Read-Execute, naively loading it will open a can of security issues. Moreover many platform data structures like Global Object Table of the dynamic executable uses addresses. You cannot simply bump things around. On top of that libraries like C++ standard library (or abseil from Google) rely on the page size to optimize data structures like hash maps (i.e. unordered_map).
- londons_explore 1y agoIf 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...
- rwmj 1y agoIs there a such a thing? Page size gets baked into things like executable layouts, plus any place that uses the PAGE_SIZE constant (instead of sysconf(_SC_PAGESIZE)).
- londons_explore 1y agoIndeed it would take redesigning a bunch of things to make runtime variable page size an option.
- bjourne 1y ago4 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.
- rwmj 1y agoFrom 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 :-)
- croemer 1y agoI think you meant "Android developers" that are forced to switch their apps.
- londons_explore 1y agoThis 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.).
- growse 1y ago> One should be able to map, protect, etc memory ranges down to byte granularity - which is the granularity of everything else in computers. But you can do this, you simply have to pay the cost of using PAGE_SIZE of memory per byte you want to protect?
- deleted 1y ago[deleted]
- ohdeargodno 1y agoDozens of years of kernel building, dozens of OSes, dozens of physical architectures, all having settled on minimum 4KB pages being a right balance between performance and memory usage, wiped away by a single offhand comment with no knowledge about the situation. Now that's HN. Just the sheer TLB memory usage and performance implication of doing single byte pages would send CPU performance back to the stone age.
- 1y ago
- croemer 1y ago"offering improved performance gains" is a pleonasm. "offering performance gains" works just fine.
- Eric_WVGG 1y ago> This table describes who needs to transition and recompile their apps information design is my passion
- butz 1y agoTable added as image, alt text vaguely explains table contents and has a spelling error. Great.
- gok 1y agoIt's kind of too bad Linux to doesn't just support multiple base page sizes.