La capacità è la quantità totale di una risorsa (CPU, GPU e così via) di cui dispone un dispositivo per un determinato periodo di tempo. Questa pagina descrive come identificare e risolvere i problemi di jitter relativi alla capacità.
Il regolatore è lento a reagire
Per evitare il jitter, il regolatore della frequenza della CPU deve essere in grado di rispondere rapidamente ai carichi di lavoro intermittenti. La maggior parte delle app di UI segue lo stesso schema di base:
- L'utente sta leggendo la schermata.
- L'utente tocca lo schermo: tocca un pulsante, scorre e così via.
- Lo schermo scorre, cambia attività o si anima in qualche modo in risposta all'input.
- Il sistema entra in stato di attesa quando vengono visualizzati nuovi contenuti.
- L'utente torna a leggere la schermata.
I dispositivi Pixel e Nexus implementano il boost tocco per modificare il comportamento del governatore (e dello scheduler) della frequenza della CPU al tocco. Per evitare un aumento lento della frequenza di clock (che potrebbe causare la perdita di frame al tocco del dispositivo), il potenziamento tocco solitamente imposta un limite di frequenza sulla CPU per garantire una grande quantità di capacità della CPU al tocco. Un piano rimane attivo per un determinato periodo di tempo dopo il tocco (in genere circa due secondi).
Pixel utilizza anche il cgroup schedtune fornito da Energy Aware Scheduling (EAS) come ulteriore indicatore di boost tocco: le app principali ricevono un peso aggiuntivo tramite schedtune per assicurarsi di avere una capacità della CPU sufficiente per funzionare rapidamente. I Nexus 5X e 6P hanno un divario di prestazioni molto più elevato tra i cluster CPU piccoli e grandi (rispettivamente A53 e A57) rispetto a Pixel con la CPU Kryo. Abbiamo riscontrato che il piccolo cluster di CPU non era sempre adeguato per un rendering fluido dell'interfaccia utente, soprattutto in considerazione di altre fonti di jitter sul dispositivo.
Di conseguenza, su Nexus 5X e 6P, il boost tocco modifica il comportamento del programmatore per aumentare la probabilità che le app in primo piano passino ai core big (il concetto è simile al limite minimo della frequenza della CPU). Senza la modifica dello schedulatore per aumentare le probabilità di spostamento delle app in primo piano nel cluster CPU grande, le app in primo piano potrebbero non avere una capacità CPU sufficiente per il rendering finché lo schedulatore non decide di bilanciare il carico del thread su un core CPU grande. Modificando il comportamento dello scheduler durante il boost tocco, è più probabile che un thread dell'interfaccia utente venga eseguito immediatamente su un core grande ed eviti il jitter, senza però forzarlo a funzionare sempre su un core grande, il che potrebbe avere gravi ripercussioni sul consumo di energia.
Ridotta potenza termica
La limitazione di temperatura si verifica quando il dispositivo deve ridurre il suo output termico complessivo, in genere riducendo la frequenza di CPU, GPU e DRAM. Non sorprende che questo spesso provochi scatti, in quanto il sistema potrebbe non essere più in grado di fornire una capacità sufficiente per il rendering in un determinato intervallo di tempo. L'unico modo per evitare il throttling termico è utilizzare meno potenza. Esistono diversi modi per farlo, ma, sulla base delle nostre esperienze con i SOC precedenti, abbiamo alcuni consigli per i fornitori di sistemi.
Innanzitutto, quando crei un nuovo SOC con architetture CPU eterogenee, assicurati che le curve di prestazioni/W dei cluster CPU si sovrappongano. La curva di rendimento/W complessiva per l'intero processore deve essere una linea continua. Le discontinuità nella curva di prestazioni/W costringono lo scheduler e il regolatore della frequenza a indovinare le esigenze di un carico di lavoro. Per evitare il jitter, lo scheduler e il regolatore della frequenza tendono a fornire al carico di lavoro più capacità di quella richiesta. Ciò comporta un consumo eccessivo di energia, che contribuisce al throttling termico.
Immagina un SOC ipotetico con due cluster di CPU:
- Il cluster 1, il cluster più piccolo, può consumare tra 100 e 300 mW e ottenere un punteggio tra 100 e 300 in un benchmark sul throughput, a seconda della frequenza.
- Il cluster 2, il cluster di grandi dimensioni, può consumare tra 1000 e 1600 mW e ottenere un punteggio tra 800 e 1200 nello stesso benchmark sul throughput a seconda della frequenza.
In questo benchmark, un punteggio più alto indica una maggiore velocità. Anche se non è più auspicabile rispetto a una velocità inferiore, più veloce significa maggiore consumo energetico.
Se lo scheduler ritiene che un carico di lavoro dell'interfaccia utente richieda un valore equivalente a 310 per il benchmark sul throughput, l'opzione migliore per evitare il jitter è eseguire il cluster di grandi dimensioni alla frequenza più bassa, sprecando una potenza significativa. (Questo dipende dal comportamento di cpuidle e dalla gara per l'idle. È più facile ottimizzare per i SoC con curve di prestazioni/W continue).
In secondo luogo, utilizza i set di CPU. Assicurati di aver attivato i set di CPU nel kernel e nel tuo BoardConfig.mk. Devi anche configurare le assegnazioni cpuset effettive nel file init.rc specifico del dispositivo. Alcuni fornitori lasciano questa opzione disattivata nei propri BSP nella speranza di poter utilizzare altri suggerimenti per influenzare il comportamento dello schedulatore. Riteniamo che questo non abbia senso. I cpuset sono utili per garantire che il bilanciamento del carico tra le CPU venga eseguito in modo da riflettere ciò che l'utente sta effettivamente facendo sul dispositivo.
ActivityManager assegna le app a diversi cpuset in base all'importanza relativa di queste app (principali, in primo piano, in background), con le app più importanti che ottengono un maggiore accesso ai core della CPU. In questo modo viene garantita la qualità del servizio per le app in primo piano e principali.
I cpuset sono utili per le configurazioni CPU omogenee, ma non devi spedire un dispositivo con una configurazione CPU eterogenea senza che i cpuset siano abilitati. Nexus 6P è un buon modello per l'utilizzo di cpuset su configurazioni CPU eterogenee; utilizzalo come base per la configurazione del tuo dispositivo.
I set CPU offrono anche vantaggi in termini di potenza garantendo che i thread in background che non sono critici per le prestazioni non vengano mai bilanciati in base al carico sui core CPU di grandi dimensioni, dove potrebbero consumare molta più energia senza alcun vantaggio percepito dall'utente. Questo può anche contribuire a evitare il throttling termico. Sebbene la limitazione termica sia un problema di capacità, i miglioramenti del jitter hanno un impatto eccessivo sulle prestazioni dell'interfaccia utente in caso di limitazione termica. Poiché il sistema funzionerà più vicino alla sua capacità di eseguire il rendering a 60 FPS, è necessario meno jitter per causare la perdita di un frame.