Novità sui prodotti

Boosting Android Performance: Introducing AutoFDO for the Kernel

Tempo di lettura: 4 min
Visualizza il profilo di Charles Munger
Yabin Cui Software Engineer

Siamo il team della toolchain LLVM di Android. Una delle nostre priorità principali è migliorare le prestazioni di Android tramite tecniche di ottimizzazione nell'ecosistema LLVM. Siamo costantemente alla ricerca di modi per rendere Android più veloce, fluido ed efficiente. Sebbene gran parte del nostro lavoro di ottimizzazione avvenga nello spazio utente, il kernel rimane il cuore del sistema. Oggi siamo felici di condividere il modo in cui stiamo introducendo l'ottimizzazione automatica basata sul feedback (AutoFDO) nel kernel Android per offrire agli utenti un notevole miglioramento delle prestazioni.

Che cos'è AutoFDO?

Durante una build software standard, il compilatore prende migliaia di piccole decisioni, ad esempio se inserire una funzione in linea e quale ramo di un'istruzione condizionale è probabile che venga eseguito, in base a suggerimenti di codice statico.Sebbene queste euristiche siano utili, non sempre prevedono con precisione l'esecuzione del codice durante l'utilizzo reale dello smartphone.

AutoFDO cambia questa situazione utilizzando pattern di esecuzione reali per guidare il compilatore. Questi pattern rappresentano i percorsi di esecuzione delle istruzioni più comuni seguiti dal codice durante l'utilizzo effettivo, acquisiti registrando la cronologia delle diramazioni della CPU. Sebbene questi dati possano essere raccolti dai dispositivi del parco risorse, per il kernel li sintetizziamo in un ambiente di laboratorio utilizzando workload rappresentativi, ad esempio l'esecuzione delle 100 app più popolari. Utilizziamo un profiler di campionamento per acquisire questi dati, identificando quali parti del codice sono "hot" (utilizzate di frequente) e quali sono "cold". Quando ricompiliamo il kernel con questi profili, il compilatore può prendere decisioni di ottimizzazione molto più intelligenti, personalizzate in base ai workload effettivi di Android.

Per comprendere l'impatto di questa ottimizzazione, considera questi fatti chiave:

  • Su Android, il kernel rappresenta circa il 40% del tempo di CPU.
  • Utilizziamo già AutoFDO per ottimizzare i file eseguibili e le librerie nativi nello spazio utente, ottenendo un miglioramento di circa il 4% nell'avvio a freddo delle app e una riduzione dell'1% del tempo di avvio.

Miglioramenti delle prestazioni nel mondo reale

Abbiamo riscontrato miglioramenti significativi nelle metriche chiave di Android sfruttando i profili di ambienti di laboratorio controllati. Questi profili sono stati raccolti utilizzando la scansione e l'avvio delle app e misurati sui dispositivi Pixel con i kernel 6.1, 6.6 e 6.12.

I miglioramenti più evidenti sono elencati di seguito. I dettagli sui profili AutoFDO per queste versioni kernel sono disponibili nei rispettivi repository del kernel Android per i kernel android16-6.12 e android15-6.6.

boosting_2.png

Non si tratta solo di numeri teorici. Si traducono in un'interfaccia più scattante, un passaggio più rapido tra le app, una durata della batteria prolungata e un dispositivo complessivamente più reattivo per l'utente finale.

Come funziona: la pipeline

La nostra strategia di deployment prevede una pipeline sofisticata per garantire che i profili rimangano pertinenti e le prestazioni stabili.

boosting_3.png

Passaggio 1: raccolta dei profili

Sebbene ci affidiamo alla nostra flotta di test interna per profilare i binari dello spazio utente, siamo passati a un ambiente di laboratorio controllato per l'immagine kernel generica (GKI). Il disaccoppiamento della profilazione dal ciclo di rilascio del dispositivo consente aggiornamenti flessibili e immediati indipendenti dalle versioni kernel di cui è stato eseguito il deployment. In particolare, i test confermano che questi dati basati su test di laboratorio offrono miglioramenti delle prestazioni paragonabili a quelli delle flotte reali.

  • Strumenti e ambiente: eseguiamo il flashing dei dispositivi di test con l'immagine kernel più recente e utilizziamo simpleperf per acquisire i flussi di esecuzione delle istruzioni. Questo processo si basa sulle funzionalità hardware per registrare la cronologia delle ramificazioni, in particolare utilizzando  ARM Embedded Trace Extension (ETE) e ARM Trace Buffer Extension (TRBE) sui dispositivi Pixel.
  • Workload: creiamo un workload rappresentativo utilizzando le 100 app più popolari della Android App Compatibility Test Suite (C-Suite). Per acquisire i dati più precisi, ci concentriamo su:
    • Lancio di app: ottimizzazione per i ritardi più visibili per gli utenti
    • Scansione delle app basata sull'AI: simulazione di interazioni utente contigue e in evoluzione
    • Monitoraggio a livello di sistema: acquisizione non solo delle attività delle app in primo piano, ma anche dei workload in background critici e delle comunicazioni tra processi.
  • Convalida: questo workload sintetizzato mostra una somiglianza dell'85% con i pattern di esecuzione raccolti dal nostro parco risorse interno.
  • Dati mirati: ripetendo questi test un numero sufficiente di volte, acquisiamo pattern di esecuzione ad alta fedeltà che rappresentano accuratamente l'interazione degli utenti reali con le applicazioni più popolari. Inoltre, questo framework estensibile ci consente di integrare perfettamente workload e benchmark aggiuntivi per ampliare la nostra copertura.

Passaggio 2: elaborazione del profilo

I dati di traccia non elaborati vengono sottoposti a post-elaborazione per garantire che siano puliti, efficaci e pronti per il compilatore.

  • Aggregazione:consolidiamo i dati di più esecuzioni di test e dispositivi in un'unica visualizzazione di sistema.
  • Conversione: convertiamo le tracce non elaborate nel formato del profilo AutoFDO, filtrando i simboli indesiderati in base alle esigenze.
  • Taglio dei profili:tagliamo i profili per rimuovere i dati delle funzioni "cold", consentendo loro di utilizzare l'ottimizzazione standard. In questo modo si evitano regressioni nel codice utilizzato raramente e aumenti non necessari delle dimensioni dei file binari.

Passaggio 3: test del profilo

Prima del deployment, i profili vengono sottoposti a una rigorosa verifica per garantire che offrano miglioramenti costanti delle prestazioni senza rischi per la stabilità.

  • Analisi del profilo e dei file binari:confrontiamo rigorosamente i contenuti del nuovo profilo (tra cui funzioni hot, conteggi dei campioni e dimensioni del profilo) con le versioni precedenti. Utilizziamo il profilo anche per creare una nuova immagine del kernel, analizzando i file binari per garantire che le modifiche alla sezione di testo siano coerenti con le aspettative.
  • Verifica delle prestazioni: eseguiamo benchmark mirati sulla nuova immagine kernel. In questo modo, si conferma che mantiene i miglioramenti delle prestazioni stabiliti dalle baseline precedenti.

Aggiornamenti continui

Il codice "deriva" naturalmente nel tempo, quindi un profilo statico alla fine perderebbe la sua efficacia. Per mantenere prestazioni ottimali, eseguiamo la pipeline in modo continuo per generare aggiornamenti regolari:

  • Aggiornamento regolare:aggiorniamo i profili nei branch LTS del kernel Android prima di ogni release della GKI, assicurandoci che ogni build includa i dati del profilo più recenti.
  • Espansione futura: al momento stiamo distribuendo questi aggiornamenti ai rami android16-6.12 e android15-6.6 ed estenderemo il supporto alle versioni GKI più recenti, come la prossima android17-6.18.

Garantire la stabilità

Una domanda comune sull'ottimizzazione basata su profilo è se introduce rischi di stabilità. Poiché AutoFDO influisce principalmente sulle euristiche del compilatore, come l'inlining delle funzioni e il layout del codice, anziché alterare la logica del codice sorgente, preserva l'integrità funzionale del kernel. Questa tecnologia è già stata testata su larga scala, fungendo da ottimizzazione standard per le librerie della piattaforma Android, ChromeOS e l'infrastruttura dei server di Google per anni.

Per garantire ulteriormente un comportamento coerente, applichiamo una strategia "conservativa per impostazione predefinita". Le funzioni non acquisite nei nostri profili ad alta fedeltà vengono ottimizzate utilizzando metodi di compilazione standard. In questo modo, le parti "fredde" o eseguite raramente del kernel si comportano esattamente come in una build standard, evitando regressioni delle prestazioni o comportamenti imprevisti in casi limite.

In futuro

Al momento stiamo implementando AutoFDO nei rami android16-6.12 e android15-6.6. Oltre a questo lancio iniziale, vediamo diverse strade promettenti per migliorare ulteriormente la tecnologia:

  • Copertura ampliata: non vediamo l'ora di implementare i profili AutoFDO nelle versioni kernel GKI più recenti e in altri target di build oltre all'attuale supporto di aarch64.
  • Ottimizzazione dei moduli GKI: al momento, la nostra ottimizzazione è incentrata sul file binario del kernel principale (vmlinux). L'espansione di AutoFDO ai moduli GKI potrebbe portare vantaggi in termini di prestazioni a una parte più ampia del sottosistema del kernel.
  • Supporto dei moduli dei fornitori:siamo anche interessati a supportare AutoFDO per i moduli dei fornitori creati utilizzando il Driver Development Kit (DDK). Con il supporto già disponibile nel nostro sistema di build (Kleaf) e negli strumenti di profilazione (simpleperf), i fornitori possono applicare queste stesse tecniche di ottimizzazione ai loro driver hardware specifici.
  • Copertura più ampia dei profili: è possibile raccogliere profili da una gamma più ampia di Critical User Journey (CUJ) per ottimizzarli.

Portando AutoFDO nel kernel Android, ci assicuriamo che le fondamenta stesse del sistema operativo siano ottimizzate per il modo in cui utilizzi il tuo dispositivo ogni giorno.

Scritto da:
Continua a leggere