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

71–80 of 173 posts

Re: Adding 16 kb page size to Android

#71

Post by ndesaulniers »

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.

Ossification.

If the page size has been 4k for decades for most OS' and architectures, people get sloppy and hard code that literal value, rather than query for it.

Re: Adding 16 kb page size to Android

#72

Post by redleader55 »

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

Re: Adding 16 kb page size to Android

#73

Post by nullindividual »

andai wrote: post #70
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 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.

Remember that Win32 process creation is expensive[0]. And on NT, processes don't run, threads do.

The strategy of applications, like olde-tymey Apache using multiple processes to handle incoming connections is fine on UN*X, but terrible on Windows.

[0] https://fourcore.io/blogs/how-a-windows-process-is-created-p...

Re: Adding 16 kb page size to Android

#74

Post by taeric »

I see they have measured improvements in the performance of some things. In particular, the camera app starts faster. Small percentage, but still real.

Curious if there are any other changes you could do based on some of those learnings? The camera app, in particular, seems like a good one to optimize to start instantly. Especially so with the the shortcut "double power key" that many phones/people have setup.

Specifically, I would expect you should be able to do something like the lisp norm of "dump image?" Startup should then largely be loading the image, not executing much if any initialization code? (Honestly, I mostly assume this already happens?)

Re: Adding 16 kb page size to Android

#75

Post by lxgr »

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…

> all old binaries break and emulators which emulate normal systems with 4KB pages

Would it actually affect the kind of emulators present on Android, i.e. largely software-only ones, as opposed to hardware virtualizers making use of a CPU's vTLB?

Wine is famously not an emulator and as such doesn't really exist/make sense on (non-x86) Android (as it would only be able to execute ARM binaries, not x86 ones).

For the downvote: Genuinely curious here on which type of emulator this could affect.

Re: Adding 16 kb page size to Android

#76

Post by stingraycharles »

Veserv wrote: post #59
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…

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 unit of memory you can allocate?

And does that then mean that there’s less overhead in all kinds of memory (pre)fetchers in the CPU, because more can be achieved in less clock cycles?

Re: Adding 16 kb page size to Android

#77

Post by Zefiroj »

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…

The support for mTHP exists in upstream Linux, but the swap story is not quite there yet. THP availability also needs work and there are a few competing directions.

Supporting multiple page sizes well transparently is non-trivial.

For a recent summary on one of the approaches, TAO (THP Allocation Optimization), see this lwn article: https://lwn.net/Articles/974636/

Re: Adding 16 kb page size to Android

#78

Post by aaron695 »

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…

[dead]

Re: Adding 16 kb page size to Android

#79

Post by david_allison »

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.

The Android Native Development Kit (NDK) allows building native code libraries for Android (typically C/C++, but this can include Rust). These can then be loaded and accessed by JNI on the Java/Kotlin side

* Brief overview of the NDK: https://developer.android.com/ndk/guides

* Guide to supporting 16KB page sizes with the NDK https://developer.android.com/guide/practices/page-sizes

Re: Adding 16 kb page size to Android

#80

Post by HeatrayEnjoyer »

thanatropism wrote: post #20
platelminto wrote: post #16

Earlier quoted context omitted.

I remember reading somewhere that LLMs are actually fantastic at reading heavily mistyped sentences! Mistyped to a level where humans actually struggle. (I will update this comment if I find a source)

Tihs probably refers to comon mispelllings an typo's.

It's actually not. You can scramble every letter within words and it can mostly unscramble it. Keep the first letter and it recovers almost 100%.
Post reply on HN