Wir sind das Android LLVM-Toolchain-Team. Eine unserer obersten Prioritäten ist die Verbesserung der Android-Leistung durch Optimierungstechniken im LLVM-Ökosystem. Wir suchen ständig nach Möglichkeiten, Android schneller, reibungsloser und effizienter zu machen. Obwohl ein Großteil unserer Optimierungsarbeit im Userspace stattfindet, bleibt der Kernel das Herz des Systems. Heute möchten wir Ihnen zeigen, wie wir die automatische Feedback-gesteuerte Optimierung (AutoFDO) in den Android-Kernel integrieren, um die Leistung für Nutzer erheblich zu verbessern.

Was ist AutoFDO?

Bei einem Standard-Softwarebuild trifft der Compiler Tausende kleiner Entscheidungen, z. B. ob eine Funktion inline ausgeführt werden soll und welcher Zweig einer Bedingung wahrscheinlich ausgeführt wird. Diese Entscheidungen basieren auf statischen Codehinweisen. Diese Heuristiken sind zwar nützlich, aber sie sagen die Codeausführung bei der tatsächlichen Nutzung des Smartphones nicht immer genau voraus.

AutoFDO ändert dies, indem es reale Ausführungsmuster verwendet, um den Compiler zu steuern. Diese Muster stellen die häufigsten Ausführungspfade für Anweisungen dar, die der Code bei der tatsächlichen Nutzung durchläuft. Sie werden erfasst, indem der Verzweigungsverlauf der CPU aufgezeichnet wird. Diese Daten können zwar von Flottengeräten erfasst werden, für den Kernel werden sie jedoch in einer Laborumgebung mit repräsentativen Arbeitslasten synthetisiert, z. B. durch Ausführen der 100 beliebtesten Apps. Wir verwenden einen Sampling-Profiler, um diese Daten zu erfassen und zu ermitteln, welche Teile des Codes „aktiv“ (häufig verwendet) und welche „inaktiv“ sind.Wenn wir den Kernel mit diesen Profilen neu erstellen, kann der Compiler viel intelligentere Optimierungsentscheidungen treffen, die auf die tatsächlichen Android-Arbeitslasten zugeschnitten sind.

Um die Auswirkungen dieser Optimierung zu verstehen, sollten Sie die folgenden wichtigen Fakten berücksichtigen:

• Unter Android macht der Kernel etwa 40% der CPU-Zeit aus.
• Wir verwenden AutoFDO bereits, um native ausführbare Dateien und Bibliotheken im Userspace zu optimieren. Dadurch wird der Start von inaktiven Apps um etwa 4% und die Bootzeit um 1% verkürzt.

Leistungssteigerungen in der Praxis

Durch die Verwendung von Profilen aus kontrollierten Laborumgebungen konnten wir beeindruckende Verbesserungen bei wichtigen Android-Messwerten erzielen. Diese Profile wurden durch App-Crawling und -Starten erfasst und auf Pixel-Geräten mit den Kerneln 6.1, 6.6 und 6.12 gemessen.

Die bemerkenswertesten Verbesserungen sind unten aufgeführt. Details zu den AutoFDO-Profilen für diese Kernelversionen finden Sie in den entsprechenden Android-Kernel-Repositories für die Kernel android16-6.12 und android15-6.6.

Das sind nicht nur theoretische Zahlen. Sie führen zu einer schnelleren Benutzeroberfläche, schnelleren App-Wechseln, einer längeren Akkulaufzeit und einem insgesamt reaktionsschnelleren Gerät für den Endnutzer.

Funktionsweise: Die Pipeline

Unsere Bereitstellungsstrategie umfasst eine ausgefeilte Pipeline, um sicherzustellen, dass die Profile relevant bleiben und die Leistung stabil bleibt.

Schritt 1: Profilerfassung

Während wir unsere interne Testflotte verwenden, um Profile von Binärdateien im Userspace zu erstellen, sind wir für das Generic Kernel Image (GKI) zu einer kontrollierten Laborumgebung gewechselt. Durch die Entkopplung der Profilerstellung vom Geräte-Releasezyklus sind flexible, sofortige Updates unabhängig von den bereitgestellten Kernelversionen möglich. Tests bestätigen, dass diese laborgestützten Daten Leistungssteigerungen liefern, die mit denen von Flotten in der Praxis vergleichbar sind.

• Tools und Umgebung: Wir flashen Testgeräte mit dem neuesten Kernel-Image und verwenden simpleperf, um Ausführungsstreams für Anweisungen zu erfassen. Dieser Prozess basiert auf Hardwarefunktionen zum Aufzeichnen des Verzweigungsverlaufs, insbesondere auf  ARM Embedded Trace Extension (ETE) und ARM Trace Buffer Extension (TRBE) auf Pixel-Geräten.
• Arbeitslasten:  Wir erstellen eine repräsentative Arbeitslast mit den 100 beliebtesten Apps aus der Android App Compatibility Test Suite (C-Suite). Um möglichst genaue Daten zu erfassen, konzentrieren wir uns auf Folgendes:
  • App-Start: Optimierung für die sichtbarsten Verzögerungen für Nutzer
  • **KI-gestütztes App-Crawling**: Simulation von zusammenhängenden, sich entwickelnden Nutzerinteraktionen
  • Systemweite Überwachung:Erfassung nicht nur von Aktivitäten im Vordergrund, sondern auch von kritischen Arbeitslasten im Hintergrund und der Kommunikation zwischen Prozessen
• Validierung:Diese synthetische Arbeitslast weist eine Ähnlichkeit von 85% mit Ausführungsmustern auf, die von unserer internen Flotte erfasst wurden.
• Zielgerichtete Daten:Durch die Wiederholung dieser Tests erfassen wir hochgenaue Ausführungsmuster, die die Nutzerinteraktion mit den beliebtesten Anwendungen in der Praxis genau widerspiegeln. Darüber hinaus können wir mit diesem erweiterbaren Framework nahtlos zusätzliche Arbeitslasten und Benchmarks integrieren, um unsere Abdeckung zu erweitern.

Schritt 2: Profilverarbeitung

Wir verarbeiten die Rohdaten nach der Erfassung, um sicherzustellen, dass sie sauber und effektiv sind und für den Compiler bereit sind.

• Aggregation:Wir konsolidieren Daten aus mehreren Testläufen und von mehreren Geräten in einer einzigen Systemansicht.
• Konvertierung: Wir konvertieren Rohdaten in das AutoFDO-Profilformat und filtern bei Bedarf unerwünschte Symbole heraus.
• Profilzuschnitt:Wir schneiden Profile zu, um Daten für „inaktive“ Funktionen zu entfernen, damit sie mit der Standardoptimierung verwendet werden können. So werden Regressionen in selten verwendetem Code verhindert und unnötige Erhöhungen der Binärgröße vermieden.

Schritt 3: Profiltests

Vor der Bereitstellung werden Profile streng überprüft, um sicherzustellen, dass sie konsistente Leistungssteigerungen ohne Stabilitätsrisiken liefern.

• Profil- und Binäranalyse:Wir vergleichen den Inhalt des neuen Profils (einschließlich aktiver Funktionen, Stichprobenanzahl und Profilgröße) genau mit früheren Versionen. Außerdem verwenden wir das Profil, um ein neues Kernel-Image zu erstellen, und analysieren Binärdateien, um sicherzustellen, dass die Änderungen am Textabschnitt den Erwartungen entsprechen.
• Leistungsüberprüfung:Wir führen gezielte Benchmarks für das neue Kernel-Image aus. So wird bestätigt, dass die Leistungssteigerungen beibehalten werden, die durch frühere Baselines erzielt wurden.

Kontinuierliche Updates

Code „driftet“ im Laufe der Zeit. Ein statisches Profil verliert daher irgendwann seine Effektivität. Um eine optimale Leistung aufrechtzuerhalten, führen wir die Pipeline kontinuierlich aus, um regelmäßige Updates zu ermöglichen:

• Regelmäßige Aktualisierung: Wir aktualisieren Profile in den LTS-Zweigen des Android-Kernels vor jedem GKI-Release, damit jeder Build die neuesten Profildaten enthält.
• Zukünftige Erweiterung:Derzeit stellen wir diese Updates für die Zweige android16-6.12 und android15-6.6 bereit und werden die Unterstützung auf neuere GKI-Versionen wie die kommende Version android17-6.18 ausweiten.

Stabilität gewährleisten

Eine häufige Frage bei der profilgesteuerten Optimierung ist, ob sie Stabilitätsrisiken birgt. Da AutoFDO in erster Linie die Heuristiken des Compilers beeinflusst, z. B. die Inline-Ausführung von Funktionen und das Code-Layout, anstatt die Logik des Quellcodes zu ändern, bleibt die funktionale Integrität des Kernels erhalten. Diese Technologie hat sich bereits in großem Maßstab bewährt und dient seit Jahren als Standardoptimierung für Android-Plattformbibliotheken, ChromeOS und die eigene Serverinfrastruktur von Google.

Um ein konsistentes Verhalten zu gewährleisten, wenden wir standardmäßig eine konservative Strategie an. Funktionen, die nicht in unseren hochgenauen Profilen erfasst werden, werden mit Standardmethoden des Compilers optimiert. So verhalten sich die „inaktiven“ oder selten ausgeführten Teile des Kernels genau wie in einem Standard-Build. Dadurch werden Leistungsregressionen oder unerwartetes Verhalten in Grenzfällen verhindert.

Unsere Zukunftspläne

Wir stellen AutoFDO derzeit für die Zweige android16-6.12 und android15-6.6 bereit. Neben dieser ersten Einführung sehen wir mehrere vielversprechende Möglichkeiten, die Technologie weiter zu verbessern:

• Erweiterte Reichweite:Wir freuen uns darauf, AutoFDO-Profile für neuere GKI-Kernelversionen und zusätzliche Build-Ziele bereitzustellen, die über die aktuelle aarch64-Unterstützung hinausgehen.
• Optimierung von GKI-Modulen:Derzeit konzentriert sich unsere Optimierung auf die Hauptbinärdatei des Kernels (vmlinux). Wenn AutoFDO auf GKI-Module ausgeweitet wird, könnte dies die Leistung eines größeren Teils des Kernel-Subsystems verbessern.
• Unterstützung von Anbietermodulen:Wir möchten auch AutoFDO für Anbietermodule unterstützen, die mit dem Driver Development Kit (DDK) erstellt wurden. Da die Unterstützung bereits in unserem Build-System (Kleaf) und den Profilerstellungstools (simpleperf) verfügbar ist, können Anbieter diese Optimierungstechniken auf ihre spezifischen Hardwaretreiber anwenden.
• Breitere Profilabdeckung:Es besteht die Möglichkeit, Profile aus einer größeren Anzahl von wichtigen Nutzerverhalten (Critical User Journeys, CUJs) zu erfassen, um sie zu optimieren.

Durch die Einführung von AutoFDO im Android-Kernel stellen wir sicher, dass die Grundlage des Betriebssystems für die Art und Weise optimiert ist, wie Sie Ihr Gerät täglich verwenden.