La capacità è la quantità totale di alcune risorse (CPU, GPU, ecc.) che un dispositivo possiede in un certo periodo di tempo. In questa pagina viene descritto come identificare e risolvere i problemi jank relativi alla capacità.
Il governatore è lento a reagire
Per evitare problemi, il regolatore di frequenza della CPU deve essere in grado di rispondere rapidamente ai carichi di lavoro intensi. La maggior parte delle applicazioni dell'interfaccia utente seguono lo stesso modello di base:
- L'utente sta leggendo lo schermo.
- L'utente tocca lo schermo: tocca un pulsante, scorre, ecc.
- Lo schermo scorre, cambia attività o si anima in qualche modo in risposta all'input.
- Il sistema entra in pausa quando viene visualizzato un nuovo contenuto.
- L'utente torna a leggere lo schermo.
I dispositivi Pixel e Nexus implementano il touch boost per modificare il comportamento del regolatore di frequenza (e dello scheduler) della CPU al tocco. Per evitare una rampa lenta verso una frequenza di clock elevata (che potrebbe causare la perdita di fotogrammi del dispositivo al tocco), l'incremento del tocco di solito imposta una frequenza minima sulla CPU per garantire che sia disponibile molta capacità della CPU al tocco. Un pavimento dura per un certo periodo di tempo dopo il tocco (di solito circa due secondi).
Pixel utilizza anche il cgroup di schedtune fornito da Energy Aware Scheduling (EAS) come ulteriore segnale di potenziamento del tocco: le applicazioni principali ottengono un peso aggiuntivo tramite schedtune per garantire che abbiano una capacità della CPU sufficiente per essere eseguite rapidamente. Il Nexus 5X e 6P hanno un divario prestazionale molto maggiore tra i cluster CPU piccoli e grandi (rispettivamente A53 e A57) rispetto al Pixel con CPU Kryo. Abbiamo scoperto che il piccolo cluster della CPU non era sempre adeguato per un rendering fluido dell'interfaccia utente, soprattutto date le altre fonti di jitter sul dispositivo.
Di conseguenza, sui Nexus 5X e 6P, il touch boost modifica il comportamento dello scheduler per rendere più probabile che le applicazioni in primo piano si spostino sui core più grandi (questo è concettualmente simile al livello minimo della frequenza della CPU). Senza la modifica dello scheduler per rendere più probabile lo spostamento delle applicazioni in primo piano nel cluster di CPU di grandi dimensioni, le applicazioni in primo piano potrebbero avere una capacità della CPU insufficiente per eseguire il rendering finché lo scheduler non decide di bilanciare il carico del thread su un core di CPU di grandi dimensioni. Modificando il comportamento dello scheduler durante il touch boost, è più probabile che un thread dell'interfaccia utente venga eseguito immediatamente su un core grande ed eviti i jank senza forzarlo a essere sempre eseguito su un core grande, il che potrebbe avere gravi ripercussioni sul consumo energetico.
Limitazione termica
La limitazione termica si verifica quando il dispositivo deve ridurre la sua potenza termica complessiva, solitamente eseguita riducendo i clock di CPU, GPU e DRAM. Non sorprende che ciò si traduca spesso in problemi poiché il sistema potrebbe non essere più in grado di fornire capacità sufficiente per il rendering entro un determinato intervallo di tempo. L'unico modo per evitare la limitazione termica è utilizzare meno energia. Non esistono molti modi per farlo, ma in base alle nostre esperienze con i SOC precedenti, abbiamo alcuni consigli per i fornitori di sistemi.
Innanzitutto, quando si crea un nuovo SOC con architetture CPU eterogenee, assicurarsi che le curve prestazioni/W dei cluster CPU si sovrappongano. La curva prestazioni/W complessiva dell'intero processore dovrebbe essere una linea continua. Le discontinuità nella curva prestazioni/W costringono lo scheduler e il regolatore di frequenza a indovinare di cosa ha bisogno un carico di lavoro; per evitare problemi, lo scheduler e il regolatore di frequenza sbagliano nel dare al carico di lavoro più capacità di quella richiesta. Ciò si traduce in un consumo eccessivo di energia, che contribuisce alla limitazione termica.
Immagina un ipotetico SOC con due cluster di CPU:
- Il cluster 1, il cluster piccolo, può spendere tra 100 e 300 mW e ottiene un punteggio di 100-300 in un benchmark di throughput a seconda del clock.
- Il cluster 2, il cluster più grande, può spendere tra 1000 e 1600 mW e ottiene punteggi tra 800 e 1200 nello stesso benchmark di throughput a seconda del clock.
In questo benchmark, un punteggio più alto corrisponde a una velocità maggiore. Sebbene non sia più desiderabile di più lento, più veloce == maggiore consumo energetico.
Se lo scheduler ritiene che un carico di lavoro dell'interfaccia utente richiederebbe l'equivalente di un punteggio di 310 su quel benchmark di throughput, la sua migliore opzione per evitare problemi è eseguire il grande cluster alla frequenza più bassa, sprecando una quantità significativa di energia. (Ciò dipende dal comportamento della CPU e dalla corsa al minimo; i SOC con curve prestazioni/W continue sono più facili da ottimizzare.)
In secondo luogo, utilizzare cpusets. Assicurati di aver abilitato i cpuset nel kernel e nel BoardConfig.mk . È inoltre necessario impostare le effettive assegnazioni del cpuset nel init.rc specifico del dispositivo. Alcuni fornitori lo lasciano disabilitato nei propri BSP nella speranza di poter utilizzare altri suggerimenti per influenzare il comportamento dello scheduler; riteniamo che questo non abbia senso. cpusets 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 tali app (in alto, in primo piano, in background), con le applicazioni più importanti che ottengono maggiore accesso ai core della CPU. Ciò contribuisce a garantire la qualità del servizio per le app in primo piano e principali.
I cpusets sono utili su configurazioni di CPU omogenee, ma non dovresti spedire un dispositivo con una configurazione di CPU eterogenea senza cpusets abilitati. Nexus 6P è un buon modello su come utilizzare cpuset su configurazioni di CPU eterogenee; usalo come base per la configurazione del tuo dispositivo.
I CPUset offrono anche vantaggi in termini di potenza garantendo che i thread in background che non sono critici per le prestazioni non vengano mai bilanciati con i core della CPU di grandi dimensioni, dove potrebbero spendere molta più energia senza alcun vantaggio percepito dall'utente. Questo può aiutare a evitare anche la limitazione termica. Sebbene la limitazione termica sia un problema di capacità, i miglioramenti del jitter hanno un impatto enorme sulle prestazioni dell'interfaccia utente durante la limitazione termica. Poiché il sistema si avvicinerà alla sua capacità di rendering a 60 FPS, è necessario un jitter inferiore per causare una perdita di fotogramma.