Siamo il team della toolchain LLVM di Android. Una delle nostre principali priorità è migliorare il rendimento 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 portando l'ottimizzazione automatica guidata dal feedback (AutoFDO) nel kernel di Android per offrire agli utenti miglioramenti significativi del rendimento.

Che cos'è AutoFDO?

Durante una build software standard, il compilatore prende migliaia di piccole decisioni, ad esempio se inserire una funzione e quale ramo di una condizione è probabile che venga 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 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 che il codice intraprende durante l'utilizzo effettivo, acquisiti registrando la cronologia dei rami della CPU. Sebbene questi dati possano essere raccolti dai dispositivi del parco risorse, per il kernel li sintetizziamo in un ambiente di lab utilizzando workload rappresentativi, ad esempio eseguendo le 100 app più popolari. Utilizziamo un profiler di campionamento per acquisire questi dati, identificando le parti del codice "hot" (utilizzate di frequente) e quelle "cold".Quando ricostruiamo il kernel con questi profili, il compilatore può prendere decisioni di ottimizzazione molto più intelligenti, personalizzate per i workload Android effettivi.

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

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

Miglioramenti del rendimento nel mondo reale

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

Di seguito sono riportati i miglioramenti più evidenti. 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.

Questi non sono solo numeri teorici. Si traducono in un'interfaccia più rapida, in un cambio di app più veloce, in una maggiore durata della batteria e in 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 che il rendimento rimanga stabile.

Passaggio 1: raccolta dei profili

Sebbene ci affidiamo alla nostra flotta di test interna per profilare i file binari dello spazio utente, siamo passati a un ambiente di laboratorio controllato per l'immagine del kernel generico (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 basati sul laboratorio offrono miglioramenti del rendimento 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 gli stream di esecuzione delle istruzioni. Questo processo si basa sulle funzionalità hardware per registrare la cronologia dei rami, utilizzando in particolare  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ù accurati, ci concentriamo su:
  • Avvio delle app: ottimizzazione per i ritardi utente più visibili
  • Crawling delle app basato 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 similarità dell'85% con i pattern di esecuzione raccolti dalla nostra flotta interna.
• 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 senza problemi workload e benchmark aggiuntivi per ampliare la nostra copertura.

Passaggio 2: elaborazione dei profili

Post-elaboriamo i dati di traccia grezzi per assicurarci 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 grezze nel formato del profilo AutoFDO, filtrando i simboli indesiderati, se necessario.
• Riduzione dei profili: riduciamo 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 dei profili

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

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

Aggiornamenti continui

Il codice "si sposta" naturalmente nel tempo, quindi un profilo statico alla fine perderebbe la sua efficacia. Per mantenere il rendimento ottimale, eseguiamo continuamente la pipeline per implementare aggiornamenti regolari:

• Aggiornamento regolare: aggiorniamo i profili nei rami LTS del kernel Android prima di ogni release GKI, assicurandoci che ogni build includa i dati dei profili più recenti.
• Espansione futura: al momento stiamo implementando questi aggiornamenti nei rami android16-6.12 e android15-6.6 ed espanderemo 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 le euristiche del compilatore, come l'inserimento delle funzioni e il layout del codice, anziché modificare la logica del codice sorgente, preserva l'integrità funzionale del kernel. Questa tecnologia è già stata collaudata su larga scala e da anni funge da ottimizzazione standard per le librerie della piattaforma Android, ChromeOS e l'infrastruttura server di Google.

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 i metodi di compilazione standard. In questo modo, le parti "cold" o eseguite raramente del kernel si comportano esattamente come in una build standard, evitando regressioni del rendimento o comportamenti imprevisti in casi limite.

In futuro

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

• Copertura ampliata: non vediamo l'ora di eseguire il deployment dei profili AutoFDO nelle versioni del kernel GKI più recenti e in altri target di build oltre all'attuale supporto 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 apportare vantaggi in termini di rendimento 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). 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 di Android, ci assicuriamo che la base stessa del sistema operativo sia ottimizzata per il modo in cui utilizzi il dispositivo ogni giorno.