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

121–130 of 173 posts

Re: Adding 16 kb page size to Android

#121

Post by versteegen »

CalChris wrote: post #118
afr0ck wrote: post #111

Earlier quoted context omitted.

Because of virtual address translation [1] speed up. When a memory access is made by a program, the CPU must first translate the virtual address to a physical address, by walking a hierarchical data structure called a page table [2]. Walking the page tables is slow, thus CPUs implement a small on-CPU cache of virtual-to-physical translations called a TLB [1]. The TLB has a limited number of entries for each page size…

Are huge pages expected to share code (X) and data (RW)?

There's probably no good reason to put code and data on the same page, it's just one extra TLB entry to use two pages instead so the data page can be marked non-executable.

Re: Adding 16 kb page size to Android

#122

Post by wren6991 »

monocasa wrote: post #2

I wonder how much help they had by asahi doing a lot of the kernel and ecosystem work anablibg 16k pages. RISC-V being fixed to 4k pages seems to be a bit of an oversight as well.

RV64 has some reserved encoding space in satp.mode so there's an obvious path to expanding the number of page table formats at a later time. Just requires everyone to agree on the direction (common issue with RISC-V).

For RV32 I think we are probably stuck with Sv32 4k pages forever.

Re: Adding 16 kb page size to Android

#124

Post by saagarjha »

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.

I am aware. This does not change what I said.

Re: Adding 16 kb page size to Android

#125

Post by quotemstr »

Veserv wrote: post #114
sweetjuly wrote: post #102

Earlier quoted context omitted.

Hmm, I'm not sure that's quite right. ARMv8 supports per TTBR translation granules [1] and so you can have 4K and 16K user processes coexisting under an arbitrary page size kernel by just context switching TCR.TG0 at the same time as TTBR0. There is no such thing as a global granule size. [1]: https://arm.jonpalmisc.com/2023_09_sysreg/AArch64-tcr_el2#fi...

Well, if you want to run headfirst into the magical land of hardware errata, I guess you could go around creating heterogeneous, switched mappings. I doubt the TCRs were ever intended to support rapid runtime switching or that the TLBs were ever intended to support heterogeneous entrys even with ASID tagging.

You've listed things that could go wrong without citing specific errata. Should we just assume that hardware doesn't work as documented? It seems premature to deem the feature buggy without having tried it.

Re: Adding 16 kb page size to Android

#126

Post by ein0p »

zahlman wrote: post #123
ein0p wrote: post #58

No mention of Apple on the page. Apple has been using 16K pages for years now.

Why would an "Android news" blog mention what competitors are doing?

Because the whole thing sounds like they’re doing something new, but they’re just catching up to something Apple has done back when they switched to aarch64.

Re: Adding 16 kb page size to Android

#129

Post by CalChris »

nullindividual wrote: post #128
CalChris wrote: post #127

iOS has had 16K pages since forever. OSX switched to 16K pages in 2020 with the M1. Windows is stuck on 4K pages, even for AArch64. Linux has various page sizes. Asahi is 16K.

Windows has 4K, 2M, and 1G page sizes on x86-64.

Normal, large and huge. But default normal pages (which is what Android is changing) are 4K. FWIW, Itanium and Alpha had 8K default pages.

https://devblogs.microsoft.com/oldnewthing/20210510-00/?p=10...

I wonder why Microsoft stayed with 4K for AArch64.

Re: Adding 16 kb page size to Android

#130

Post by afr0ck »

versteegen wrote: post #117
afr0ck wrote: post #111

Earlier quoted context omitted.

Because of virtual address translation [1] speed up. When a memory access is made by a program, the CPU must first translate the virtual address to a physical address, by walking a hierarchical data structure called a page table [2]. Walking the page tables is slow, thus CPUs implement a small on-CPU cache of virtual-to-physical translations called a TLB [1]. The TLB has a limited number of entries for each page size…

> I'm happy to talk about this all day! Oh really :) I'd like to ask how applications should change their memory allocation or usage patterns to maximise the benefit of THP. Do memory allocators (glibc mainly) need config tweaking to coalesce tiny mallocs into 2MB+ mmaps, will they just always do that automatically, do you need to use a custom pool allocator so you're doing large allocations, or are you never going t…

In current Linux systems, there are two main ways to benefit from huge pages. 1) There is the explicit, user-managed approach via hugetlbfs. That's not very common. 2) Transparently managed by the kernel via THP (userpsace is completely unaware and any application using mmap() and malloc() can benefit from that).

As I mentioned before, most major Linux distributions ship with THP enabled by default. THP automatically allocates huge pages for mmap memory whenever possible (that is when, at least, the region is 2 MiB aligned and is at least 2 MiB in size). There is also a separate kernel thread, khugepaged, that opportunistically tries to coalesce/promote base 4K pages into 2 MiB huge pages, whenever possible.

Library support is not really required for THP, but could be detrimental for its performance and availability on the long run. A library that is not aware of kernel huge pages may employ suboptimal memory management strategies, resulting in inefficient utilization, for example by unintentionally breaking those huge pages (e.g. via unaligned unmapping), or failing to properly release them to the OS as one full unit, undermining their availability on the long run. Afaik, Tcmalloc from Google is the only library with extensive huge page awareness [1].

> Do the heuristics used by Linux THP (khugepaged) really allow completely ignoring whether pages have actually been page-faulted in or even initialised? Is a possibility unlikely to happen in practice?

Linux allocates huge pages on first touch. For khugepaged, it only coalesces the pages if all the base pages covering the 2 MiB virtual region exist in some form (not necessary faulted-in. For example, some of those base pages could be in swap space and Linux will first fault them in then migrate them)

[1] https://www.usenix.org/system/files/osdi21-hunter.pdf

Post reply on HN