Android-Leistung steigern: AutoFDO für den Kernel

Wir sind das Android LLVM-Toolchain-Team. Eine unserer obersten Prioritäten ist es, die Android-Leistung durch Optimierungstechniken im LLVM-Ökosystem zu verbessern. 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 (Automatic Feedback-Directed Optimization, AutoFDO) in den Android-Kernel integrieren, um Nutzern erhebliche Leistungssteigerungen zu ermöglichen.

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 Geräten in der Flotte 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 konnten wir den Kaltstart von Apps um etwa 4% und die Bootzeit um 1% verbessern.

Leistungssteigerungen in der Praxis

Wir haben beeindruckende Verbesserungen bei wichtigen Android-Messwerten erzielt, indem wir Profile aus kontrollierten Laborumgebungen genutzt haben. 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 bedeuten für den Endnutzer eine schnellere Benutzeroberfläche, schnellere App-Wechsel, eine längere Akkulaufzeit und ein insgesamt reaktionsschnelleres Gerät.

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 realen Flotten 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 der  ARM Embedded Trace Extension (ETE) und der 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 Hintergrundarbeitslasten und Interprozesskommunikation
• Validierung:Diese synthetische Arbeitslast weist eine Ähnlichkeit von 85% mit Ausführungsmustern auf, die von unserer internen Flotte erfasst wurden.
• Zielgerichtete Daten:Durch Wiederholen dieser Tests erfassen wir hochgenaue Ausführungsmuster, die die reale Nutzerinteraktion mit den beliebtesten Anwendungen genau darstellen. 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, effektiv 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.
• Profilbereinigung:Wir bereinigen Profile, 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 Binärdateien zu analysieren, 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, daher würde ein statisches Profil irgendwann seine Wirksamkeit verlieren. Um eine maximale 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 jeder GKI-Version, 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äufig gestellte 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 Standardbuild. Dadurch werden Leistungsregressionen oder unerwartetes Verhalten in Grenzfällen verhindert.

Zukunftspläne

Wir stellen AutoFDO derzeit in den Zweigen android16-6.12 und android15-6.6 bereit. Neben dieser ersten Bereitstellung 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 über die aktuelle aarch64-Unterstützung hinaus bereitzustellen.
• 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 zu Leistungssteigerungen für einen größeren Teil des Kernel-Subsystems führen.
• Unterstützung von Anbietermodulen:Wir möchten AutoFDO auch 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 Critical User Journeys (CUJs) zu erfassen, um sie zu optimieren.

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