Produktneuigkeiten

Android-Leistung steigern: Einführung von AutoFDO für den Kernel

Lesezeit: 4 Minuten
Profil von Charles Munger ansehen
Yabin Cui Software Engineer

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. Ein Großteil unserer Optimierungsarbeit findet zwar im Userspace statt, aber der Kernel bleibt das Herzstück des Systems. Heute möchten wir euch zeigen, wie wir die automatische feedbackgesteuerte Optimierung (AutoFDO) in den Android-Kernel integrieren, um die Leistung für Nutzer deutlich zu verbessern.

Was ist AutoFDO?

Während eines standardmäßigen Software-Builds trifft der Compiler Tausende von kleinen Entscheidungen, z. B. ob eine Funktion inline eingefügt werden soll und welcher Zweig einer Bedingung wahrscheinlich genommen wird, basierend auf statischen Codehinweisen. Diese Heuristiken sind zwar nützlich, aber sie sagen die Codeausführung während 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 Verwendung nimmt. Sie werden durch Aufzeichnen des Verzweigungsverlaufs der CPU erfasst. Diese Daten können zwar von Geräten in der Flotte erhoben werden, für den Kernel synthetisieren wir sie jedoch in einer Laborumgebung mit repräsentativen Arbeitslasten, 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 „heiß“ (häufig verwendet) und welche „kalt“ 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 sich die folgenden wichtigen Fakten ansehen:

  • 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 die Kaltstartzeit von Apps um etwa 4 % und die Bootzeit um 1 % reduzieren.

Leistungssteigerungen in der Praxis

Wir haben durch die Nutzung von Profilen aus kontrollierten Laborumgebungen beeindruckende Verbesserungen bei wichtigen Android-Messwerten festgestellt. Diese Profile wurden mithilfe von App-Crawling und ‑Starts erfasst und auf Pixel-Geräten mit den Kernel-Versionen 6.1, 6.6 und 6.12 gemessen.

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

boosting_2.png

Das sind nicht nur theoretische Zahlen. Sie sorgen für eine schnellere Benutzeroberfläche, schnelleres Wechseln zwischen Apps, eine längere Akkulaufzeit und ein insgesamt reaktionsschnelleres Gerät für die Endnutzer.

So funktionierts: Die Pipeline

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

boosting_3.png

Schritt 1: Profilsammlung

Während wir uns bei der Profilerstellung von Userspace-Binärdateien auf unsere interne Testflotte verlassen, haben wir für das Generic Kernel Image (GKI) auf eine kontrollierte Laborumgebung umgestellt. Durch die Entkopplung der Profilerstellung vom Releasezyklus des Geräts sind flexible, sofortige Updates unabhängig von den bereitgestellten Kernel-Versionen möglich. Tests bestätigen, dass diese im Labor erhobenen 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 die Ausführung von Befehlen zu erfassen. Dieser Prozess basiert auf Hardwarefunktionen zum Aufzeichnen des Verzweigungsverlaufs. Auf Pixel-Geräten werden dazu insbesondere die  ARM Embedded Trace Extension (ETE) und die ARM Trace Buffer Extension (TRBE) verwendet.
  • 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 am besten sichtbaren Nutzerverzögerungen
    • KI-gestütztes App-Crawling: Simulation zusammenhängender, sich entwickelnder Nutzerinteraktionen
    • Systemweites Monitoring: Erfassung nicht nur von App-Aktivitäten im Vordergrund, sondern auch von kritischen Hintergrundarbeitslasten und der Kommunikation zwischen Prozessen
  • Validierung: Diese synthetisierte Arbeitslast weist eine 85%ige Ähnlichkeit mit Ausführungsmustern auf, die von unserer internen Flotte erfasst wurden.
  • Zielgerichtete Daten: Durch ausreichendes Wiederholen dieser Tests erfassen wir hochpräzise Ausführungsmuster, die die tatsächliche Nutzerinteraktion mit den beliebtesten Anwendungen genau darstellen. Darüber hinaus können wir dank dieses erweiterbaren Frameworks zusätzliche Arbeitslasten und Benchmarks nahtlos integrieren, um die Abdeckung zu erweitern.

Schritt 2: Profilverarbeitung

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

  • Aggregation: Wir fassen Daten aus mehreren Testläufen und Geräten in einer einzigen Systemansicht zusammen.
  • Konvertierung:  Wir konvertieren Roh-Traces in das AutoFDO-Profilformat und filtern bei Bedarf unerwünschte Symbole heraus.
  • Profilkürzung: Wir kürzen Profile, um Daten für „kalte“ Funktionen zu entfernen, damit sie die Standardoptimierung verwenden können. So werden Regressionen in selten verwendetem Code verhindert und unnötige Erhöhungen der Binärgröße vermieden.

Schritt 3: Profil testen

Vor der Bereitstellung werden Profile strengen Prüfungen unterzogen, um sicherzustellen, dass sie ohne Stabilitätsrisiken eine konsistente Leistungssteigerung bieten.

  • Profil- und Binäranalyse: Wir vergleichen den Inhalt des neuen Profils (einschließlich Hot Functions, Stichprobenanzahl und Profilgröße) strikt mit früheren Versionen. Wir verwenden das Profil auch, um ein neues Kernel-Image zu erstellen. Dabei analysieren wir Binärdateien, um sicherzustellen, dass Ä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 mit früheren Referenzwerten erzielten Leistungsverbesserungen beibehalten werden.

Kontinuierliche Updates

Code „driftet“ im Laufe der Zeit auf natürliche Weise ab, sodass ein statisches Profil irgendwann seine Wirksamkeit verlieren würde. Damit die Leistung auf einem hohen Niveau bleibt, führen wir die Pipeline kontinuierlich aus, um regelmäßige Updates zu ermöglichen:

  • Regelmäßige Aktualisierung: Wir aktualisieren die Profile in LTS-Branches des Android-Kernels vor jedem GKI-Release, damit jeder Build die neuesten Profildaten enthält.
  • Zukünftige Erweiterung: Wir stellen diese Updates derzeit für die Branches 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 zur profilgesteuerten Optimierung ist, ob sie Stabilitätsrisiken mit sich bringt. Da AutoFDO hauptsächlich Compiler-Heuristiken wie Funktions-Inlining und Code-Layout beeinflusst, anstatt die Logik des Quellcodes zu ändern, bleibt die funktionale Integrität des Kernels erhalten. Diese Technologie hat sich bereits im großen 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 eine „standardmäßig konservative“ Strategie an. Funktionen, die nicht in unseren High-Fidelity-Profilen erfasst werden, werden mit Standard-Compiler-Methoden optimiert. So wird sichergestellt, dass sich die „kalten“ oder selten ausgeführten Teile des Kernels genau so verhalten wie in einem Standard-Build. Dadurch werden Leistungseinbußen oder unerwartetes Verhalten in Grenzfällen verhindert.

Unsere Zukunftspläne

Wir stellen AutoFDO derzeit in den Zweigen android16-6.12 und android15-6.6 bereit. Über diese erste Einführung hinaus sehen wir mehrere vielversprechende Möglichkeiten, die Technologie weiter zu verbessern:

  • Erweiterte Reichweite: Wir freuen uns darauf, AutoFDO-Profile auf neueren GKI-Kernel-Versionen und zusätzlichen Build-Zielen über die aktuelle aarch64-Unterstützung hinaus bereitzustellen.
  • Optimierung von GKI-Modulen: Derzeit konzentriert sich unsere Optimierung auf die Haupt-Kernel-Binärdatei (vmlinux). Die Ausweitung von AutoFDO auf GKI-Module könnte die Leistung eines größeren Teils des Kernel-Subsystems verbessern.
  • Unterstützung für Herstellermodule: Wir möchten AutoFDO auch für Herstellermodule unterstützen, die mit dem Driver Development Kit (DDK) erstellt wurden. Da die Unterstützung bereits in unserem Build-System (Kleaf) und in unseren Profiling-Tools (simpleperf) verfügbar ist, können Anbieter diese Optimierungstechniken auch 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 Integration von AutoFDO in den Android-Kernel wird die Grundlage des Betriebssystems für die tägliche Nutzung optimiert.

Verfasst von:
Weiterlesen