Miglioramento delle prestazioni di Android: introduzione di AutoFDO per il kernel

Siamo il team della toolchain LLVM di Android. Una delle nostre principali priorità è migliorare le prestazioni di Android attraverso 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 come stiamo introducendo l'ottimizzazione automatica basata sul feedback (AutoFDO) nel kernel Android per offrire agli utenti miglioramenti significativi delle prestazioni.

Che cos'è AutoFDO?

Durante una build software standard, il compilatore prende migliaia di piccole decisioni, ad esempio se incorporare una funzione e quale ramo di una condizione verrà probabilmente eseguito, in base a suggerimenti di codice statici.Sebbene queste euristiche siano utili, non sempre prevedono con precisione l'esecuzione del codice durante l'utilizzo dello smartphone nel mondo reale.

AutoFDO cambia questa situazione utilizzando pattern di esecuzione reali per guidare il compilatore. Questi pattern rappresentano i percorsi di esecuzione delle istruzioni più comuni che il codice segue 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 vengono sintetizzati in un ambiente di lab utilizzando carichi di lavoro rappresentativi, ad esempio l'esecuzione delle 100 app più popolari. Utilizziamo un profiler di campionamento per acquisire questi dati, identificando le parti del codice "calde" (utilizzate di frequente) e quelle "fredde". Quando ricompiliamo il kernel con questi profili, il compilatore può prendere decisioni di ottimizzazione molto più intelligenti e personalizzate in base ai carichi di lavoro Android effettivi.

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

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

Vittorie nelle prestazioni nel mondo reale

Abbiamo notato miglioramenti impressionanti in tutte le 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 del kernel sono disponibili nei rispettivi repository del kernel Android per i kernel android16-6.12 e android15-6.6.

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

Come funziona: la pipeline

La nostra strategia di implementazione prevede una pipeline sofisticata per garantire che i profili rimangano pertinenti e che il rendimento rimanga stabile.

Passaggio 1: raccolta dei profili

Sebbene ci affidiamo alla nostra flotta di test interni per profilare i binari dello spazio utente, siamo passati a un ambiente di laboratorio controllato per l'immagine generica del kernel (GKI). Il disaccoppiamento della profilazione dal ciclo di rilascio del dispositivo consente aggiornamenti flessibili e immediati indipendentemente dalle versioni del kernel di cui è stato eseguito il deployment. È fondamentale sottolineare che i test confermano che questi dati 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 del 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, utilizzando in particolare  ARM Embedded Trace Extension (ETE) e ARM Trace Buffer Extension (TRBE) sui dispositivi Pixel.
• Carichi di lavoro: costruiamo un carico di lavoro rappresentativo utilizzando le 100 app più popolari della Android App Compatibility Test Suite (C-Suite). Per acquisire i dati più precisi, ci concentriamo su:
  • Avvio di app: ottimizzazione per i ritardi più visibili per gli utenti
  • Scansione delle app basata sull'AI: simulazione di interazioni utente contigue ed evolutive
  • 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 a sufficienza, acquisiamo pattern di esecuzione ad alta fedeltà che rappresentano con precisione l'interazione utente reale con le applicazioni più popolari. Inoltre, questo framework estensibile ci consente di integrare facilmente benchmark e workload aggiuntivi per ampliare la nostra copertura.

Passaggio 2: elaborazione del profilo

Post-elaboriamo i dati di traccia non elaborati per assicurarci che siano puliti, efficaci e pronti per il compilatore.

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

Passaggio 3: test del profilo

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

• Analisi di profili e binari: confrontiamo rigorosamente i contenuti del nuovo profilo (incluse le funzioni più utilizzate, i conteggi dei campioni e le 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 del rendimento:eseguiamo benchmark mirati sulla nuova immagine del kernel. Ciò conferma che mantiene i miglioramenti del rendimento stabiliti dalle baseline precedenti.

Aggiornamenti continui

Il codice "cambia" naturalmente nel tempo, quindi un profilo statico alla fine perderebbe la sua efficacia. Per mantenere il massimo rendimento, eseguiamo la pipeline in modo continuo per fornire aggiornamenti regolari:

• Aggiornamento regolare:aggiorniamo i profili nei rami 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 frequente sull'ottimizzazione guidata dal profilo è se introduce rischi per la stabilità. Poiché AutoFDO influenza principalmente l'euristica 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 e funge da ottimizzazione standard per le librerie della piattaforma Android, ChromeOS e l'infrastruttura server di Google da 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 più ampia: non vediamo l'ora di implementare i profili AutoFDO nelle versioni più recenti del kernel GKI e in ulteriori target di build oltre all'attuale supporto di aarch64.
• Ottimizzazione dei moduli GKI:al momento, la nostra ottimizzazione è incentrata sul binario del kernel principale (vmlinux). L'espansione di AutoFDO ai moduli GKI potrebbe apportare vantaggi in termini di prestazioni a una parte più ampia del sottosistema del kernel.
• Supporto dei moduli del fornitore:ci interessa anche supportare AutoFDO per i moduli del fornitore creati utilizzando il Driver Development Kit (DDK). Grazie al supporto già disponibile nel nostro sistema di compilazione (Kleaf) e negli strumenti di profilazione (simpleperf), i fornitori possono applicare queste stesse tecniche di ottimizzazione ai propri driver hardware specifici.
• Copertura più ampia dei profili:è possibile raccogliere profili da una gamma più ampia di percorsi utente critici (CUJ) per ottimizzarli.

Portando AutoFDO nel kernel Android, ci assicuriamo che la base stessa del sistema operativo sia ottimizzata per il modo in cui utilizzi il tuo dispositivo ogni giorno.