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

Adding 16 kb page size to Android

android-developers.googleblog.com

Post reply on HN
Print view View original

61–70 of 173 posts

Re: Adding 16 kb page size to Android

#61

Post by growse »

a1o wrote: post #7

> The very first 16 KB enabled Android system will be made available on select devices as a developer option. This is so you can use the developer option to test and fix > once an application is fixed to be page size agnostic, the same application binary can run on both 4 KB and 16 KB devices I am curious about this. When could an app NOT be agnostic to this? Like what an app must be doing to cause this to be noticea…

If you use a database library that does mmap to create a db file with SC_PAGE_SIZE (4KB) pages, and then upgrade your device to a 16KB one and backup/restore the app, now your data isn't readable.

Re: Adding 16 kb page size to Android

#62

Post by nullindividual »

tredre3 wrote: post #55
mananaysiempre wrote: post #44

Earlier quoted context omitted.

This seems especially peculiar given Windows has a 64K mapping granularity.

Windows uses 4KB pages.

4K, 2M ("large page"), or 1G ("huge page") on x86-64. A single allocation request can consist of multiple page sizes. From Windows Internal 7th Edt Part 1:

    On Windows 10 version 1607 x64 and Server 2016 systems, large pages may also be mapped with huge pages, which are 1 GB in size. This is done automatically if the allocation size requested is larger than 1 GB, but it does not have to be a multiple of 1 GB. For example, an allocation of 1040 MB would result in using one huge page (1024 MB) plus 8 “normal” large pages (16 MB divided by 2 MB).

Re: Adding 16 kb page size to Android

#63

Post by scottlamb »

daghamm wrote: post #57

Can someone explain those numbers to me? 5-10% performance boost sounds huge. Wouldn't we have much larger TLBd if page walk was really this expensive? On the other hand 9% increase in memory usage also sounds huge. How did this affect memory usage that much?

> 5-10% performance boost sounds huge. Wouldn't we have much larger TLBd if page walk was really this expensive?

It's pretty typical for large programs to spend 15+% of their "CPU time" waiting for the TLB. [1] So larger pages really help, including changing the base 4 KiB -> 16 KiB (4x reduction in TLB pressure) and using 2 MiB huge pages (512x reduction where it works out).

I've also wondered why the TLB isn't larger.

> On the other hand 9% increase in memory usage also sounds huge. How did this affect memory usage that much?

This is the granularity at which physical memory is assigned, and there are a lot of reasons most of a page might be wasted:

* The heap allocator will typically cram many things together in a page, but it might say only use a given page for allocations in a certain size range, so not all allocations will snuggle in next to each other.

* Program stacks each use at least one distinct page of physical RAM because they're placed in distinct virtual address ranges with guard pages between. So if you have 1,024 threads, they used at least 4 MiB of RAM with 4 KiB pages, 16 MiB of RAM with 16 KiB pages.

* Anything from the filesystem that is cached in RAM ends up in the page cache, and true to the name, it has page granularity. So caching a 1-byte file would take 4 KiB before, 16 KiB after.

[1] If you have an Intel CPU, toplev is particularly nice for pointing this kind of thing out. https://github.com/andikleen/pmu-tools

Re: Adding 16 kb page size to Android

#64

Post by daghamm »

arghwhat wrote: post #11
twoodfin wrote: post #4

A little additional background: iOS has used 16KB pages since the 64-bit transition, and ARM Macs have inherited that design.

A more relevant bit of background is that 4KB pages lead to quite a lot of overhead due to the sheer number of mappings needing to be configured and cached. Using larger pages reduce overhead, in particular TLB misses as fewer entries are needed to describe the same memory range. While x86 chips mainly supports 4K, 2M and 1G pages, ARM chips tend to support more practical 16K page sizes - a nice balance between perfo…

IIRC, 64-bit ARM can do 4K, 16K, 64K and 2M pages. But there are some special rules for the last one.

https://documentation-service.arm.com/static/64d5f38f4a92140...

Re: Adding 16 kb page size to Android

#66

Post by mananaysiempre »

tredre3 wrote: post #55
mananaysiempre wrote: post #44

Earlier quoted context omitted.

This seems especially peculiar given Windows has a 64K mapping granularity.

Windows uses 4KB pages.

Right (on x86-32 and -64, because you can’t have 64KB pages there, though larger page sizes do exist and get used). You still cannot (e.g.) MapViewOfFile() on an address not divisible by 64KB, because Alpha[1]. As far as I understand, Windows is mostly why the docs for the Blink emulator[2] (a companion project of Cosmopolitan libc) tell you any programs under it need to use sysconf(_SC_PAGESIZE) [aka getpagesize() aka getauxval(AT_PAGESZ)] instead of assuming 4KB.

[1] https://devblogs.microsoft.com/oldnewthing/20031008-00/?p=42...

[2] https://github.com/jart/blink/blob/master/README.md#compilin...

Re: Adding 16 kb page size to Android

#67

Post by Dwedit »

mgaunard wrote: post #48
devit wrote: post #41

Seems pretty dubious to do this without adding support for having both 4KB and 16KB processes at once to the Linux kernel, since it means all old binaries break and emulators which emulate normal systems with 4KB pages (Wine, console emulators, etc.) might dramatically lose performance if they need to emulate the MMU. Hopefully they don't actually ship a 16KB default before supporting 4KB pages as well in the same ke…

why does it break userland? if you need to know the page size, you should query sysconf SC_PAGESIZE.

Emulating a processor with 4K size pages becomes much higher performance if you can use real addresses directly.

Re: Adding 16 kb page size to Android

#68

Post by fweimer »

mgaunard wrote: post #48
devit wrote: post #41

Seems pretty dubious to do this without adding support for having both 4KB and 16KB processes at once to the Linux kernel, since it means all old binaries break and emulators which emulate normal systems with 4KB pages (Wine, console emulators, etc.) might dramatically lose performance if they need to emulate the MMU. Hopefully they don't actually ship a 16KB default before supporting 4KB pages as well in the same ke…

why does it break userland? if you need to know the page size, you should query sysconf SC_PAGESIZE.

It should not break userland. GNU/Linux (not necessarily Android though) has supported 64K pages pretty much from the start because that was the originally page size chosen for server-focus kernels and distributions. But there are some things that need to be worked around.

Certain build processes determine the page size at compile time and assume it's the same at run time, and fail if it is not: https://github.com/jemalloc/jemalloc/issues/467

Some memory-mapped files formats have assumptions about page granularity: https://bugzilla.redhat.com/show_bug.cgi?id=1979804

The file format issue applies to ELF as well. Some people patch their toolchains (or use suitable linker options) to produce slightly smaller binaries that can only be loaded if the page size is 4K, even though the ABI is pretty clear in that you should link for compatibility with up to 64K pages.

Re: Adding 16 kb page size to Android

#69

Post by warkdarrior »

dotancohen wrote: post #32
o11c wrote: post #23

Earlier quoted context omitted.

The fundamental problem is that system headers don't provide enough information. In particular, many programs need both "min runtime page size" and "max runtime page size" (and by this I mean non-huge pages). If you call `mmap` without constraint, you need to assume the result will be aligned to at least "min runtime page size". In practice it is probably safe to assume 4K for this for "normal" systems, but I've seen…

Yes, but the context here is Java or Kotlin running on Android, not embedded C. Or do some Android applications run embedded C with only a Java UI? I'm not an Android dev.

Apps written in Flutter/Dart and React Native/Javascript both compile to native code with only shims to interface with the Java UI framework.

Re: Adding 16 kb page size to Android

#70

Post by andai »

nullindividual wrote: post #49
andai wrote: post #22

Earlier quoted context omitted.

A lot of low level stuff is a lot slower on Windows, let alone the GUI. There's also entire blogs cataloging an abundance of pathological performance issues. The one I notice the most is the filesystem. Running Linux in VirtualBox, I got 7x the host speed for many small file operations. (On top of that Explorer itself has its own random lag.) I think a better question is how much performance are they leaving on the t…

> The one I notice the most is the filesystem. This is due to the extensible file system filter model in place; I'm not aware of another OS that implements this feature and is primarily used for antivirus, but can be used by any developer for any purpose. It applies to all file systems on Windows. DevDrive[0] is Microsoft's current solution to this. > Meanwhile Win10 Explorer opens after a noticeable delay This could…

I'm glad you mentioned that. I noticed when running "Hello world" C program on Windows 10 that Windows performs over 100 reads of the Registry before running the program. Same thing when I right click a file...

A few of those are 3rd party, but most are not.

Post reply on HN