Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Transition to using 16 KB page sizes for Android apps and games

android-developers.googleblog.com

Post reply on HN
Print view View original

21–30 of 70 posts

Re: Transition to using 16 KB page sizes for Android apps and games

#21

Post by okanat »

nephanth wrote: post #18

From 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?

Because 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).

Re: Transition to using 16 KB page sizes for Android apps and games

#22

Post by tux3 »

userbinator wrote: post #2

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: https://www.kernel.org/doc/html/next/arm64/memory.html

64K 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.

Re: Transition to using 16 KB page sizes for Android apps and games

#23

Post by londons_explore »

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...

Re: Transition to using 16 KB page sizes for Android apps and games

#24

Post by HPsquared »

mkw5053 wrote: post #8

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 b…

Could they find those by setting page size to some absurdly large value like 1MB?

Re: Transition to using 16 KB page sizes for Android apps and games

#25

Post by magnat »

nephanth wrote: post #18

From 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?

Mostly for I/O, e.g. mmap requires file offset to be multiple of the page size.

Re: Transition to using 16 KB page sizes for Android apps and games

#27

Post by rwmj »

londons_explore wrote: post #23

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...

Is 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)).

Re: Transition to using 16 KB page sizes for Android apps and games

#28

Post by londons_explore »

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.).

Re: Transition to using 16 KB page sizes for Android apps and games

#29

Post by growse »

londons_explore wrote: post #28

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 lev…

> 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?

Re: Transition to using 16 KB page sizes for Android apps and games

#30

Post by pjmlp »

nubinetwork wrote: post #4

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?

They already force apps to update to new APIs every couple of years, it was the only way to stop developers to keep using deprecated stuff.
Post reply on HN