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

81–90 of 173 posts

Re: Adding 16 kb page size to Android

#81

Post by fpoling »

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.

Chrome browser on Android uses the same code base as Chrome on desktop including multi-process architecture. But it’s UI is in Java communicating with C++ using JNI.

Re: Adding 16 kb page size to Android

#82

Post by IshKebab »

stingraycharles wrote: post #76
Veserv wrote: post #59

Earlier quoted context omitted.

Having both 4KB and 16KB simultaneously is either easy or hard depending on which hardware feature they are using for 16KB pages. If they are using the configurable granule size, then that is a system-wide hardware configuration option. You literally can not map at smaller granularity while that bit is set. You might be able to design a CPU that allows your idea of partial pages, but there be dragons. If they are not…

I’m a total idiot, how exactly is page size a CPU issue rather than a kernel issue? Is it about memory channel protocols / communication? Disks have been slowly migrating away from the 4kb sector size, is this a same thing going on? That you need to actual drive to support it, because of internal structuring (i.e. how exactly the CPU aligns things in RAM), and on some super low level 4kb / 16kb being the smallest uni…

The CPU has hardware that does a page table walk automatically when you access an address for which the translation is not cached in the TLB. Otherwise virtual memory would be really slow.

Since the CPU hardware itself is doing the page table walk it needs to understand page tables and page table entries etc. including how big pages are.

Also you need to know how big pages are for the TLB itself.

The value of 4kB itself is pretty much arbitrary. It has to be a small enough number that you don't waste a load of memory by mapping memory that isn't used (e.g. if you ask for 4.01kB you're actually going to get 8kB), but a large enough number that you aren't spending all your time managing tiny pages.

That's why increasing the page size makes things faster but waste more memory.

4kB arguably isn't optimal anymore since we have way more memory now than when it was de facto standardised so it doesn't matter as much if we waste a bit. Maybe.

Re: Adding 16 kb page size to Android

#83

Post by bri3d »

dmytroi wrote: post #10
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…

Also ELF segment alignment, which is defaults to 4k.

Only on Android, for what it's worth; most "vanilla" Linux aarch64 linkers chose 64K defaults several years ago. But yes, most Android applications with native (NDK) binaries will need to be rebuilt with the new 16kb max-page-size.

Re: Adding 16 kb page size to Android

#84

Post by Alifatisk »

evilduck wrote: post #13
ashkankiani wrote: post #3

Earlier quoted context omitted.

It's pretty cool that I can read "anablibg" and know that means "enabling." The brain is pretty neat. I wonder if LLMs would get it too. They probably would.

Question I wrote: > I encountered the typo "anablibg" in the sentence "I wonder how much help they had by asahi doing a lot of the kernel and ecosystem work anablibg 16k pages." What did they actually mean? GPT-4o and Sonnet 3.5 understood it perfectly. This isn't really a problem for the large models. For local small models: * Gemma2 9b did not get it and thought it meant "analyzing". * Codestral (22b) did not it ge…

Is there any task Gemma is better at compared to others?

Re: Adding 16 kb page size to Android

#85

Post by temac »

Const-me wrote: post #40
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 I’m not sure it’s the file system per se, I believe the main reason is the security model. NT kernel has rather sophisticated security. The securable objects have security descriptors with many access control entries and auditing rules, which inherit over file system and other hierarchies according to some simple rules e.g. allow+deny=deny. Trustees are members of multipl…

I've been trying to use auditing rules for a usage that seems completely in scope and obvious to prioritize from a security point of view (tracing access to EFS files and/or the keys allowing the access) and my conclusion was that you basically can't, the doc is garbage, the implementation is probably ad-hoc with lots of holes, and MS probably hasn't prioritised the maintenance of this feature since several decades (too busy adding ads in the start menu I guess)

The NT security descriptors are also so complex they are probably a little useless in practice too, because it's too hard to use correctly. On top of that the associated Win32 API is also too hard to use correctly to the point that I found an important bug in the usage model described in MSDN, meaning that the doc writer did not know how the function actually work (in tons of cases you probably don't hit this case, but if you start digging in all internal and external users, who knows what you could find...)

NT was full of good ideas but the execution is often quite poor.

Re: Adding 16 kb page size to Android

#86

Post by fpoling »

stingraycharles wrote: post #76
Veserv wrote: post #59

Earlier quoted context omitted.

Having both 4KB and 16KB simultaneously is either easy or hard depending on which hardware feature they are using for 16KB pages. If they are using the configurable granule size, then that is a system-wide hardware configuration option. You literally can not map at smaller granularity while that bit is set. You might be able to design a CPU that allows your idea of partial pages, but there be dragons. If they are not…

I’m a total idiot, how exactly is page size a CPU issue rather than a kernel issue? Is it about memory channel protocols / communication? Disks have been slowly migrating away from the 4kb sector size, is this a same thing going on? That you need to actual drive to support it, because of internal structuring (i.e. how exactly the CPU aligns things in RAM), and on some super low level 4kb / 16kb being the smallest uni…

Samsung SSD still reports to the system that their logical sector size is 512 bytes. In fact one of the recent models even removed the option to reconfigure the disk to use 4k logical sectors. Presumably Samsung has figured that since the physical sector is much larger and they need complex mapping of logic sectors in any case, they decided not to support 4K option and stick with 512 bytes.

Re: Adding 16 kb page size to Android

#87

Post by rincebrain »

redleader55 wrote: post #72
nullindividual wrote: post #49

Earlier quoted context omitted.

> 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 not aware of another OS that implements this feature I'm not sure this is exactly what you mean, but Linux has inotify and all sorts of BPF hooks for filtering various syscalls, for example file operations.

FSFilters are basically a custom kernel module that can and will do anything they want on any filesystem access. (There's also network filters, which is how things like WinPcap get implemented.)

So yes, you could implement something similar in Linux, but there's not, last I looked, a prebuilt toolkit and infrastructure for them, just the generic interfaces you can use to hook anything.

(Compare the difference between writing a BPF module to hook all FS operations, and the limitations of eBPF, to having an InterceptFSCalls struct that you define in your custom kernel module to run your own arbitrary code on every access.)

Re: Adding 16 kb page size to Android

#88

Post by rincebrain »

eyalitki wrote: post #51

RHEL tried that in that past with 64KB on AARCH64, it led to MANY bugs all across the software stack, and they eventually reverted it - https://news.ycombinator.com/item?id=27513209 . I'm impressed by the effort on Google's side, yet I'll be surprised if this effort will pay off.

I didn't realize they had reverted it, I used to run RHEL builds on Pi systems to test for 64k page bugs because it's not like there's a POWER SBC I could buy for this.

Re: Adding 16 kb page size to Android

#89

Post by temac »

nabla9 wrote: post #47
saagarjha wrote: post #31

Earlier quoted context omitted.

Probably very little, since the Android ecosystem is quite divorced from the Linux one.

Android kernel is a mainstream Linux kernel, with additional drivers, and other functionality.

The linux kernel already works perfectly fine with various base page sizes.

Re: Adding 16 kb page size to Android

#90

Post by quotemstr »

Good. It's about time. 4KB pages come down to us from 32-bit time immemorial. We didn't bump the page size when we doubled the sizes of pointers and longs for the 64-bit transition. 4KB has been way too small for ages, and I'm glad we're biting the minor compatibility bullet and adopting a page size more suited to modern computing.
Post reply on HN