In che modo EAS contribuisce a rendere Google Pixel il telefono Android più veloce

Molto tempo fa, quando Linux era solo un'idea nella mente di Linus Torvalds, le CPU erano entità single-core che richiedevano un'enorme quantità di energia per poca potenza. Il primo processore disponibile in commercio, l'Intel 4004, funzionava con una frequenza di clock di 740kHz su un singolo core. Allora non era necessario un pianificatore di carico. La pianificazione del carico era riservata ai "colossi" dual-core come l'IBM Power 4 uscito alcuni decenni dopo. Funzionavano a una velocità bestiale da 1,1 GHz a 1,9 GHz e richiedevano programmi e sistema per utilizzare correttamente questi core. Come siamo passati da queste macchine agli algoritmi software che utilizzano più core? Potresti aver già sentito parlare di Energy Aware Scheduling (EAS) sui nostri forum. È uno dei motivi per cui gli smartphone Google Pixel funzionano così bene. Cosa c'è di così straordinario nell'EAS e come siamo arrivati ​​a questo punto? Prima di poterlo spiegare, dobbiamo parlare dei load scheduler di Linux.

---

L'evoluzione dei load scheduler di Linux

Pianificazione Round-Robin

L'elaborazione round robin è un concetto semplice da spiegare e comprendere, e ancora più semplice da coglierne gli svantaggi. Il round robin utilizza il time slicing per allocare tempo a ciascun processo. Supponiamo di avere quattro processi in esecuzione sul nostro computer.

• Processo A
• Processo B
• Processo C
• Processo D

Ora svolgiamo il lavoro dello scheduler round-robin. Assegneremo 100 millisecondi (time-slicing) a ciascun processo prima di passare a quello successivo. Ciò significa che il processo A può impiegare 100 millisecondi per eseguire l'elaborazione, quindi passa al processo B e così via. Se il lavoro di un'applicazione richiede 250 millisecondi, sarà necessario ripetere questo processo 3 volte solo per completare il suo lavoro! Ora ridimensionalo su diversi core, in modo che Processo A e Processo B siano allocati al core 1 e Processo C e Processo D siano allocati al core 2. Questa è stata sostituita dalla pianificazione O(n) (che era come il round robin, ma utilizzava le epoche e consentiva l'allocazione dinamica dei tempo), poi la pianificazione O(1) (overhead ridotto al minimo, supporto illimitato del processo), quindi infine lo scheduler completamente corretto (CFS). CFS è stato incorporato nella versione 2.6.23 del kernel Linux nell'ottobre 2007. Da allora è stato revisionato ed è ancora lo scheduler predefinito nei sistemi Linux.

Programmatore completamente corretto

Il Completely Fair Scheduler esiste in Android sin dal suo inizio e viene utilizzato su dispositivi non grandi. PICCOLI dispositivi. Utilizza un algoritmo intelligente per determinare l'ordine di elaborazione, il tempo assegnato, ecc. È un esempio di implementazione funzionante dell'algoritmo di pianificazione ben studiato chiamato "Weighted Fair Queing". Fondamentalmente si concentra sul fornire priorità ai processi di sistema e ad altri processi ad alta priorità in esecuzione sul file macchina. Se dovesse funzionare alla grande. PICCOLO dispositivo, tutti i core verrebbero percepiti come uguali. Ciò è negativo, poiché i core a basso consumo potrebbero essere costretti a eseguire applicazioni intensive o, peggio ancora, potrebbe verificarsi il contrario. La decodifica per l'ascolto della musica può essere effettuata sul big core, ad esempio, aumentando inutilmente il consumo energetico. Questo è il motivo per cui abbiamo bisogno di un nuovo scheduler per big. LITTLE, uno che possa effettivamente riconoscere e utilizzare la differenza nei core in modo efficiente dal punto di vista energetico. È qui che entra in gioco Heterogeneous Multi-Processing (HMP), lo scheduler di carico standard attualmente in esecuzione sulla maggior parte dei telefoni Android.

Multiprocessing eterogeneo

Questo è lo scheduler di carico standard per qualsiasi big. PICCOLO dispositivo uscito negli ultimi anni, diverso dal Google Pixel. HMP utilizza il big. Architettura LITTLE, che delega il lavoro meno intenso e a bassa priorità ai piccoli core che consumano meno energia. L'HMP è "sicuro" in quanto sa cosa dovrebbe andare ai nuclei grandi e cosa dovrebbe andare ai nuclei piccoli, senza commettere errori. Funziona e basta e richiede molto meno sforzo per l'impostazione dal punto di vista dello sviluppo rispetto a qualcosa come EAS, di cui parleremo tra poco. HMP è solo un'estensione di CFS per renderlo consapevole del potere.

L'HMP non accetta ipotesi, né prevede processi futuri. Questo è positivo, ma è anche il motivo per cui il dispositivo non può essere fluido come quelli che utilizzano EAS ed è anche il motivo per cui consuma leggermente più batteria. Questo, infine, ci porta all'Energy Aware Scheduling (EAS), che credo fermamente sarà il futuro nello sviluppo di ROM e kernel man mano che sempre più OEM lo adotteranno.

Pianificazione consapevole dell'energia

L'Energy Aware Scheduling (EAS) è la prossima grande novità di cui parlano gli utenti sui nostri forum. Se utilizzi un OnePlus 3 (o un Google Pixel, ovviamente) ne avrai sicuramente sentito parlare nei forum. È stato lanciato nel mainstream con Qualcomm Snapdragon 845, quindi se hai uno di questi dispositivi hai già uno smartphone abilitato EAS. EAS sotto forma di kernel come RenderZenith e ROM come VertexOS E PureFusion stavano prendendo d'assalto i forum di OnePlus 3 nel suo periodo migliore. Naturalmente, Google Pixel viene fornito anche con EAS. Con le promesse di una maggiore durata della batteria e prestazioni migliori, qual è il problema?

La pianificazione Energy Aware non è così semplice in quanto non è universale per tutti i dispositivi come CFS o HMP. L'EAS richiede la comprensione del processore su cui è in esecuzione, sulla base di un modello energetico. Questi modelli energetici sono realizzati da team di ingegneri che testano e lavorano costantemente per fornire prestazioni ottimali. Poiché Snapdragon 820 e 821 sono sostanzialmente gli stessi, i kernel personalizzati su OnePlus 3 utilizzano il modello energetico di Google Pixel. I dispositivi con Snapdragon 845 possono utilizzare EAS e OnePlus 6 lo fa in una certa misura. Non è ottimizzato come lo sarebbe un dispositivo Google Pixel, ma fa il suo lavoro. Ecco un esempio di come, nonostante OnePlus 6 abbia un processore migliore con EAS, Pixel 2 XL lo batte comunque in fluidità. Entrambe queste immagini sono state prese dalla ns revisione orientata alla velocità dell'OnePlus 6.

Se hai difficoltà a comprendere i grafici, puoi dare un'occhiata all'immagine qui sotto per avere indicazioni. Tutto ciò che supera la linea verde indica fotogrammi persi e, nei casi peggiori, balbuzie evidenti.

L'implementazione di EAS su OnePlus 6 è interessante, in quanto non sembra essere un'implementazione completa come quella che potresti trovare su un Google Pixel con lo stesso SoC. Anche i parametri sintonizzabili dello scheduler non hanno molto senso, quindi questo probabilmente spiega perché non è efficiente in termini di prestazioni come ci si aspetterebbe. È estremamente conservativo nel consumo energetico, con il sistema che dà priorità ai core a basso consumo per la maggior parte del lavoro.

I parametri sintonizzabili sono semplicemente un insieme di parametri che vengono passati al regolatore della CPU, che modifica il modo in cui il regolatore reagisce a determinate situazioni in termini di frequenza. Lo scheduler decide quindi dove collocare le attività sui diversi processori. I parametri sintonizzabili di OnePlus 6 sono impostati per dare priorità al lavoro sui core a bassa potenza. Inoltre, non aiuta il fatto che Google Pixel 2 abbia un'enorme quantità di boost di input, mantenendo tutti gli 8 core sempre online. Google utilizza anche un bilanciatore di interruzione che aiuta a rimuovere i cali di frame e migliorare le prestazioni.

Allora come funziona l'EAS? Perché è così efficace solo in determinate condizioni?

L’Energy Aware Scheduling introduce la necessità di utilizzare un modello energetico e, come accennato in precedenza, richiede molti test e lavoro per renderlo perfetto. L’EAS tenta di unificare tre diverse parti fondamentali del kernel che agiscono tutte in modo indipendente e il modello energetico aiuta a unificarle.

• Scheduler Linux (CFS, menzionato sopra)
• CPU Linux
• Frequenza cpu di Linux

Unificare tutte e 3 le parti sotto lo scheduler e calcolarle insieme offre un potenziale di risparmio energetico, poiché calcolarle insieme consente loro di essere il più efficienti possibile. CPUIdle cerca di decidere quando la CPU deve entrare in modalità inattiva, mentre CPUFreq cerca di decidere quando aumentare o diminuire la CPU. Entrambi questi moduli hanno l'obiettivo primario del risparmio energetico. Non solo, classifica quindi i processi in quattro cgroup, ovvero app superiore, sfondo del sistema, primo piano e sfondo. Le attività da elaborare vengono inserite in una di queste categorie, quindi alla categoria viene assegnata la potenza della CPU e il lavoro viene delegato su diversi core della CPU. top-app ha la massima priorità di completamento, seguita da primo piano, sfondo e quindi system- background. Tecnicamente il background ha la stessa priorità di system- background, ma system- background di solito ha accesso anche a più piccoli core. In effetti, Energy Aware Scheduling sta prendendo le parti fondamentali del kernel Linux e unificandole tutte in un unico processo.

Quando si riattiva il dispositivo, EAS sceglierà il core nello stato di inattività meno profondo, riducendo al minimo l'energia necessaria per riattivare il dispositivo. Ciò aiuta a ridurre la potenza richiesta nell'utilizzo del dispositivo, poiché non riattiverà il cluster di grandi dimensioni se non è necessario. Anche il monitoraggio del carico è una parte estremamente cruciale dell'EAS e sono disponibili due opzioni. Il "Per-Entity Load Tracking" (PELT) viene solitamente utilizzato per il monitoraggio del carico, le informazioni vengono quindi utilizzate per decidere le frequenze e come delegare le attività attraverso la CPU. È possibile utilizzare anche il "monitoraggio del carico assistito da finestra" (WALT) ed è ciò che viene utilizzato su Google Pixel. Molte ROM EAS sui nostri forum, come VertexOS, scelgono di utilizzare WALT. Molte ROM rilasceranno due versioni del kernel con WALT o PELT, quindi spetta all'utente decidere. WALT è più veloce, con picchi elevati nella frequenza della CPU mentre PELT cerca di rimanere più coerente. Il tracker del carico in realtà non influisce sulla frequenza della CPU, dice semplicemente al sistema qual è l'utilizzo della CPU. Un utilizzo maggiore della CPU richiede una frequenza più elevata e quindi una caratteristica costante di PELT è che fa sì che la frequenza della CPU aumenti o diminuisca lentamente. PELT tende a deviare verso rapporti di carico della CPU più elevati, quindi potrebbe fornire prestazioni più elevate con un costo della batteria più elevato. Nessuno può realmente dire in questo momento quale sistema di monitoraggio del carico sia migliore, poiché entrambi i metodi di monitoraggio del carico vengono continuamente aggiornati e perfezionati.

In ogni caso è ovvio che, indipendentemente dal metodo di monitoraggio del carico utilizzato, si verifica un aumento dell'efficienza. Invece di limitarsi a elaborare le attività su qualsiasi processore, l'attività viene analizzata e viene stimata la quantità di energia richiesta per eseguirla. Questo posizionamento intelligente delle attività significa che le attività vengono completate in modo molto più efficiente, rendendo allo stesso tempo il sistema più veloce nel suo insieme. L'obiettivo di EAS è ottenere l'interfaccia utente più fluida possibile con un consumo energetico minimo. È qui che entrano in gioco altri componenti esterni come schedtune.

Schedtune è definito in ciascun cgroup da due parametri sintonizzabili che garantiscono un controllo più preciso sulle attività da completare. Non controlla solo la distribuzione delle attività su più CPU, ma anche se il carico percepito deve essere gonfiato per garantire che le attività urgenti vengano completate più rapidamente. In questo modo, le applicazioni e i servizi in primo piano di cui si avvale l'utente non rallenteranno e causeranno inutili problemi di prestazioni.

Anche se la pianificazione energetica consapevole è il prossimo grande passo, si può anche sostenere che è già qui ed è lì da un po'. Con un numero sempre maggiore di dispositivi dotati di Energy Aware Scheduling, è arrivata una nuova era di efficienza dell'elaborazione mobile.

I pro e i contro di Round-Robin, CFS, HMP e EAS

Anche se le mie capacità grafiche sono scadenti, ho messo insieme un'immagine che dovrebbe riassumere quali sono i pro e i contro di ciascuno di questi scheduler.

---

Vorrei estendere un ringraziamento speciale al collaboratore riconosciuto XDA Mostafa Wael le cui spiegazioni sui vari aspetti dell'EAS hanno contribuito notevolmente a rendere possibile questo articolo. Vorrei anche ringraziare XDA Recognized Developer gioioso, sviluppatore riconosciuto XDA RenderBroken E Mostafa Wael per il suo articolo sull'EAS. Per quelli di voi che hanno riscontrato interesse per le parti relative all'EAS, Linaro ha molta documentazione sull'EAS che potete leggere.