Adding 16 kb page size to Android

Original Article ↗ Hacker News Discussion ↗

Context and comparisons to other systems

  • iOS and Apple Silicon macOS have used 16 KB pages for years; Linux on some platforms (Asahi, some Debian/RHEL flavors, Nvidia Grace-Hopper) also explores 16–64 KB.
  • Windows remains on 4 KB base pages (with 2 MB/1 GB “large/huge” pages) even on ARM64, partly to ease x86 compatibility.
  • Prior attempts (e.g., RHEL’s 64 KB pages on AArch64) exposed many bugs and were eventually reverted.

Why 16 KB pages / performance arguments

  • Larger base pages reduce TLB pressure and page-table overhead, which can be a big slice of runtime; reported 5–10% app speedups are seen as plausible.
  • Bigger pages also help VIPT caches and allow larger L1 caches with fewer synonym issues, as seen in Apple designs.
  • Huge pages (2 MB, 1 GB) already provide big wins for databases, hypervisors, and managed runtimes; 16 KB is viewed as a more “everyday” compromise.

Compatibility and software breakage

  • Apps break when they hardcode 4 KB: custom allocators, direct mmap/munmap use, ELF segment alignment, database formats, and runtimes like jemalloc and Wine.
  • File formats and on-disk layouts that assume 4 KB (including mmapped DBs) can become unreadable on 16 KB systems.
  • Toolchains and linkers often bake in page-size assumptions; Android NDK apps generally need rebuilding for a higher max page size.
  • Some argue code should always use sysconf(_SC_PAGESIZE) etc., but decades of 4 KB ossified assumptions.

Mixed page sizes, CPU design, and kernel strategy

  • Proper support for coexisting 4 KB and 16 KB user processes is non-trivial; depends on ARM’s translation granules and TLB behavior.
  • RISC-V’s fixed 4 KB base pages plus extensions like Svnapot are debated; some see them as inferior to ARM’s configurable-granule approach.
  • Transparent huge pages and newer schemes (mTHP, TAO) show that multi-size support is complex even on desktop Linux.

I/O, flash, and other side topics

  • Larger RAM pages likely don’t hurt flash much: NAND internally uses much larger erase blocks and controllers already do wear-leveling and write coalescing.
  • Bigger pages increase memory waste (fragmentation, per-thread stacks, page cache granularity); a ~9% RAM overhead is seen as significant but perhaps acceptable.

Skepticism and impact on devices

  • Some see this as overdue modernization; others worry it will further penalize low-RAM or older phones by increasing memory pressure.
  • Google’s track record on Android compatibility is viewed as mixed: better than some platforms, but willing to break older apps when pushing architecture changes.