Android erhält 16-KB-Seitengröße

• Eine Seite ist die kleinste Einheit, in der ein Betriebssystem den Speicher verwaltet
• Die meisten CPUs unterstützen eine Seitengröße von 4 KB, und Android OS sowie Anwendungen sind auf 4-KB-Seitengrößen optimiert
• ARM-CPUs unterstützen 16-KB-Seitengrößen; wenn Android diese Größe verwendet, verbessert sich die Leistung um 5–10 %, während der Speicherverbrauch um etwa 9 % steigt
• Um die Gesamtleistung des Betriebssystems zu verbessern und Geräteherstellern die Wahl dieses Trade-offs zu ermöglichen, kann Android 15 mit 4-KB- oder 16-KB-Seitengröße ausgeführt werden
• Die ersten Android-Systeme mit Unterstützung für 16-KB-Seitengrößen werden auf einigen Geräten als Entwickleroption verfügbar sein

Technische Details zur 16-KB-Seitengröße

• Die meisten CPUs verfügen über dedizierte Hardware namens Memory Management Unit (MMU), die die von Programmen verwendeten Adressen in physische Speicherorte übersetzt
• Diese Übersetzung erfolgt in Einheiten der Seitengröße
  • Immer wenn ein Programm mehr Speicher benötigt, muss das Betriebssystem eingreifen, Einträge in der „Seitentabelle“ füllen und diesen Speicherblock dem Prozess zuweisen
• Wenn die Seitengröße viermal größer wird, reduziert sich dieser Verwaltungsaufwand um den Faktor vier.
  • Dadurch kann das System mehr Zeit darauf verwenden, Videos gut aussehen zu lassen, Spiele flüssig auszuführen und Apps geschmeidig laufen zu lassen, und weniger Zeit auf die Betriebssystem-Verwaltung auf niedriger Ebene verwenden
• Die Seitengröße ist kein Application Binary Interface (ABI)
• Das heißt: Wenn eine Anwendung so angepasst wird, dass sie unabhängig von der Seitengröße ist, kann dasselbe Anwendungs-Binary sowohl auf 4-KB- als auch auf 16-KB-Geräten laufen
• In Android 15 wurde Android von Grund auf so refaktoriert, dass es mit verschiedenen Seitengrößen laufen kann und nicht mehr an eine bestimmte Seitengröße gebunden ist

Wichtige Änderungen im OS

• Geräte auf Basis von Android 15:
  • Das Compile-Time-Makro PAGE_SIZE wurde durch das Runtime-getpagesize(2) ersetzt
  • Alle OS-Binaries sind auf 16 KB ausgerichtet (Drittanbieter-Anwendungen/-Bibliotheken sind möglicherweise nicht auf 16 KB ausgerichtet)
  • Alle OS-Binaries werden mit einem separaten ladbaren Segment gebaut, damit alle in einen Prozess gemappten Speicherbereiche lesbar sind; einige Anwendungen sind davon abhängig
  • Mehrere OS-Komponenten wurden neu geschrieben, damit sie keine Annahmen über die Seitengröße treffen und für größere Seitengrößen optimiert sind

Dateisystem

• Für gute Leistung sollte die Blockgröße des Dateisystems mit der Seitengröße übereinstimmen. Die Dateisysteme EROFS und F2FS sowie die UFS-Storage-Schicht sind mit 16 KB kompatibel
• Auf 4-KB-Systemen steigt die Größe von ELF-Executables durch zusätzliches Padding für die 16-KB-Ausrichtung, aber mehrere Optimierungen vermeiden diese Kosten
• Read-only-Sparse-Dateisysteme sorgen dafür, dass für die 16-KB-Ausrichtung erzeugte Nullseiten nicht auf die Festplatte geschrieben werden
• Lese-/Schreib-Dateisysteme behandeln Nullseiten fallweise

Speicherverwaltung

• Der Linux-Seitencache wurde so angepasst, dass für diesen zusätzlichen Padding-Bereich nicht vorgelesen wird, was unnötige Speicher-Ladevorgänge spart
• Diese Seiten sind leeres Padding und werden vom Programm nie gelesen. Sie liegen nur aus Ausrichtungsgründen zwischen den tatsächlich nutzbaren Teilen des Programms

Linux-Kernel

• Der Linux-Kernel ist eng an eine bestimmte Seitengröße gekoppelt, daher muss beim Bauen des Kernels die zu verwendende Seitengröße ausgewählt werden; der Rest des Betriebssystems bleibt gleich

Android-Anwendungen

• Alle Anwendungen mit nativem Code oder nativen Abhängigkeiten müssen neu kompiliert werden, damit sie mit Geräten mit 16-KB-Seitengröße kompatibel sind
• Der meiste native Code in Android-Anwendungen und SDKs wurde mit Blick auf 4-KB-Seitengrößen gebaut; daher muss er auf 16 KB neu ausgerichtet werden, damit die Binaries sowohl auf 4-KB- als auch auf 16-KB-Geräten kompatibel sind
• Für die meisten Anwendungen und SDKs ist das ein zweistufiger Prozess:
  1. Nativen Code mit 16-KB-Ausrichtung neu bauen
  2. Auf 16-KB-Geräten/Emulatoren testen und gegebenenfalls hartcodierte Annahmen zur Seitengröße beheben

Entwicklung für 16-KB-Geräte

• Aktuell produzierte Android-Geräte unterstützen noch keine 16-KB-Seitengröße
  • Um dieses Problem zu lösen, arbeitet man mit Partnern daran, Entwickleroptionen auf bestehenden Geräten verfügbar zu machen
• Unterstützung für 16-KB-Seitengrößen wird als Entwickleroption bereitgestellt
• In Android Studio steht ein 16-KB-Emulator-Target zur Verfügung

16-KB-Entwickleroption

• In Android 15 wurde eine Entwickleroption implementiert, mit der zwischen 16-KB- und 4-KB-Seitengröße gewechselt werden kann
• Verfügbar auf Pixel 8 und Pixel 8 Pro, weitere Geräte sollen folgen
• Um die Entwickleroption zu verwenden, muss das Gerät zurückgesetzt und der Bootloader entsperrt werden

16 KB auf x86_64-Desktops

• Auf x86_64-Emulatoren kann eine 16-KB-Seitengröße emuliert werden
• Im Android Studio SDK Manager kann ein 16-KB-Seiten-Emulator heruntergeladen und gestartet werden

Zukunft

• Android 15 und AOSP unterstützen 16-KB-Seiten und können per Entwickleroption entsprechend konfiguriert werden
• Es wird erwartet, dass Anwendungs- und SDK-Entwickler diese Option nutzen, um leistungsfähigere und effizientere Android-Geräte vorzubereiten

Meinung von GN⁺

• Der Wechsel zu 16-KB-Seitengrößen ist eine wichtige Änderung zur Verbesserung von Leistung und Effizienz von Android-Geräten
• Durch die Verwendung größerer Seitengrößen kann der Overhead der Speicherverwaltung sinken und die Gesamtleistung des Systems steigen
• Allerdings kann diese Änderung auch Kompatibilitätsprobleme verursachen, insbesondere bei Apps und SDKs, die auf nativen Code angewiesen sind; Entwickler sollten ihre Software daher mit Blick auf 16-KB-Seitengrößen aktualisieren
• Google stellt Entwicklern mit der 16-KB-Entwickleroption und Emulator-Unterstützung Werkzeuge bereit, um diesen Übergang zu testen und sich darauf vorzubereiten
• 16-KB-Seiten gelten derzeit nur für ARM-basierte Android-Geräte, könnten in Zukunft aber auf andere Hardware-Plattformen ausgeweitet werden
• Entwickler sollten neben der Anpassung ihrer Apps und SDKs an 16-KB-Seitengrößen auch die Auswirkungen größerer Seiten auf den Speicherverbrauch berücksichtigen und bei Bedarf Speicheroptimierungen vornehmen
• Der Übergang zu 16-KB-Seiten ist eine wichtige Anstrengung, die Zusammenarbeit über das gesamte Android-Ökosystem hinweg erfordert, letztlich aber bessere Leistung und Effizienz für Nutzer bringen wird

[GN⁺]

Hacker-News-Kommentare

• Im Debian-Kernel wurde kürzlich damit begonnen, den ARM64-Kernel mit einer Seitengröße von 16 KiB zu bauen

  • Eine zusätzliche Unterstützung für 64-KiB-Seitengröße wird ebenfalls diskutiert
  • Es wird ein Effizienzgewinn erwartet, da die DART-IOMMU des Apple M1 mindestens eine Seitengröße von 16 KiB erfordert

• Das erste Android-System mit 16-KB-Unterstützung soll auf einigen Geräten als Entwickleroption verfügbar werden

  • Über die Entwickleroption kann getestet und angepasst werden
  • Anwendungs-Binärdateien, die unabhängig von der Seitengröße sind, laufen sowohl auf 4-KB- als auch auf 16-KB-Geräten

• Es stellt sich die Frage, wann Anwendungen nicht unabhängig von der Seitengröße sind

  • Man möchte wissen, in welchen Situationen dieses Problem auftritt

• Es ist problematisch, standardmäßig 16 KB zu verwenden, ohne gleichzeitig 4-KB- und 16-KB-Prozesse zu unterstützen

  • Ältere Binärdateien könnten kaputtgehen, und es gibt Bedenken wegen einer Verschlechterung der Emulator-Performance
  • Es wird ein Kernel benötigt, der auch 4-KB-Seiten unterstützt
  • Es wäre sinnvoll, CPU-Designs so zu gestalten, dass Einträge in 16-KB-Seitentabellen in 4-KB-Einheiten gemappt werden können

• iOS verwendet seit der Umstellung auf 64 Bit 16-KB-Seiten

  • ARM-Macs haben dieses Design ebenfalls übernommen

• RHEL hatte in der Vergangenheit auf AARCH64 64-KB-Seiten versucht, dies aber wegen vieler Bugs letztlich zurückgenommen

  • Die Bemühungen von Google sind beeindruckend, aber ob sie erfolgreich sein werden, ist fraglich

• Man fragt sich, wie sehr Asahi bei der Kernel- und Ökosystem-Arbeit geholfen hat, um 16-KB-Seiten zu aktivieren

  • Dass RISC-V auf 4-KB-Seiten festgelegt ist, wirkt wie ein Fehler

• iOS verwendet schon seit Langem 16K-Seiten

  • OSX wechselte mit dem M1 im Jahr 2020 ebenfalls zu 16K-Seiten
  • Windows bleibt auch auf AArch64 bei 4K-Seiten
  • Linux unterstützt verschiedene Seitengrößen. Asahi nutzt 16K

• Man fragt sich, ob eine größere Seitengröße die I/O-Performance oder die Lebensdauer von Flash negativ beeinflusst

  • Ebenso stellt sich die Frage, ob die Schreibeinheit moderner verwalteter Flash-Geräte größer ist als 4 KB oder 16 KB

• Performance-Verbesserungen wurden gemessen

  • Vor allem die Kamera-App startet schneller
  • Man fragt sich, welche weiteren Optimierungsmöglichkeiten es gibt
  • Es stellt sich die Frage, ob sich Initialisierungscode ähnlich wie bei einem Lisp-„Image Dump“ minimieren ließe

• Eine Performance-Steigerung von 5–10 % wirkt erheblich

  • Wenn Page Walks so teuer sind, fragt man sich, ob es nicht größere TLBs geben sollte
  • Auch der Anstieg des Speicherverbrauchs um 9 % wirkt groß
  • Man möchte wissen, wie sich das auf den Speicherverbrauch ausgewirkt hat

[gurugio]

• Da aktuelle Speichergeräte IO intern im Cache des Speichers ablegen, ist zu erwarten, dass selbst bei 16 KB großen IOs kein großer Unterschied entsteht.
• Die Leistung von Geräten, bei denen Performance wichtig ist und die zusammenhängende Seiten zugewiesen bekommen, etwa Kamera und GPU, wird verbessert.
• Da die TLB ein Hardware-Cache ist, dürften die Kosten problematisch sein.
• Offenbar wird davon ausgegangen, dass ein Anstieg des Speicherverbrauchs um 10 % im Verhältnis zur Speichergröße moderner Modelle kein größeres Problem darstellt.
• 4k und 16k gleichzeitig zu unterstützen, erfordert meiner Meinung nach Änderungen vom CPU-Kern bis zu Teilen des Kernel-Kerns, daher halte ich das für nahezu unmöglich. Da der Kernel große Seitenfunktionen wie Hugepages schon seit Langem nutzt, dürfte der Betrieb mit 16k kein großes Problem sein. Probleme außerhalb des Kernels, etwa in Android-Funktionen oder Apps, müsste Google dann wohl handhaben.
• Wie auch immer: In einer Situation, in der bei 64-Bit-Kernen der Speicher immer größer wird, wird eine Vergrößerung der Seitengröße im Servermarkt schon seit Langem diskutiert. Ich denke, dass dies nun auch bei Smartphones unausweichlich wird.