Un viaggio attraverso il kernel - Parte 2a

Eccoci con la seconda parte di questo editoriale sul kernel Android. Dopo aver introdotto alcuni concetti base sul kernel Linux nel primo articolo (che potete trovare qui), oggi parleremo in maniera molto approfondita di alcuni concetti, parametri, impostazioni relativi al kernel e per la precisione, alla CPU, alla GPU ed ai concetti ad essi connessi.
Non andremo invece a parlare di driver e simili poiché la modifica di tali porzioni di codice non involve direttamente l'utente finale, bensì soltanto il developer.

Come abbiamo detto in precedenza, il kernel si occupa della gestione dell'hardware e della comunicazione di questo con il software (ossia la ROM stessa), invocando uno o più componenti per volta per eseguire i task imposti dal sistema. Uno di questi componenti hardware è la CPU (Central Processing Unit), ossia il processore, che si occupa dell'esecuzione delle istruzioni dettate dal sistema e comunicate attraverso il kernel.

Guardiamo un po' alle caratteristiche di questo componente fondamentale nel complesso del device.
Nel caso del nostro device, il processore ha un'architettura ARM a 32bit (Advanced RISC Machine), diversa da quella dei desktop pc. Differisce da questi per un diverso TDP (Thermal Design Power), ossia quantità di energia dissipata (i processori desktop variano dai 10 ai 100+ Watt, mentre quelli ARM vanno dai 250mW ai 2+ Watt), da diversi livelli di cache allocata e da frequenze differenti (in linea di massima inferiori, ma non per molto).
Le CPU ARM, infatti, hanno una velocità di clock misurata dai 600mhz dei device low entry, fino ai +2.2ghz per core dei device più potenti. Il processore possiede una moltitudine di parametri modificabili dall'utente root atti a migliorare le performance o ad orientare il tutto al risparmio energetico. Tale predisposizione alla modifica (o tweak) fa della CPU il componente hardware più modificabile.

Come funziona la CPU? Il processore riceve dei processi dai programmi in esecuzione da eseguire dalla memoria RAM per poi scriverli sul disco fisso. Questi processi vengono gestiti ed ordinati dallo Scheduler I/O per essere sistemati a seconda della priorità che hanno. Questi possono essere eseguiti più o meno velocemente e questo aspetto viene deciso dal Governor.
Se avete familiarità con il mondo del modding, avrete sentito già parlare di queste due "entità" informatiche. Praticamente qualunque custom kernel disponibile che da accesso root, da la possibilità di modificare questi due parametri in base alle proprie necessità. Ma spesso, chi effettua questi cambiamenti lo fa per sentito dire o poco più, ma senza sapere cosa ci sia dietro ad ogni governor ed ogni scheduler e quindi non può decidere quale sia quello che più si confà alle sue necessità. Questa guida vuole dissipare questi dubbi, per cui vediamo le differenze che si frappongono tra i vari governor ed i vari scheduler.

GOVERNOR

I governor possono essere catalogati in 4 categorie (non ufficiali s'intende):

1. Quelli basati sul governor Ondemand
2. Quelli basati sul governor Conservative
3. Quelli basati sul governor Interactive
4. Quelli che usano principi propri

Vediamo i primi 3, capostipiti delle rispettive famiglie.

Uno dei più diffusi, è senza dubbio Ondemand, equipaggiato nella stragrande maggioranza dei kernel stock e presente, comunque, in quasi tutti i custom kernel (anche se non per forza di default). Tuttavia, nonostante sia praticamente ovunque, non è uno dei migliori, tutt'altro: difatti, quando un processo arriva alla CPU, l'ondemand fa balzare la frequenza di clock al massimo disponibile, per poi abbassarla gradualmente nel caso non ci siano altri processi in coda. Facile capire che una tale gestione della CPU fa sì che la batteria sia messa sotto sforza, poiché, parlando in termini molto semplici, se un processo necessitasse di una frequenza di 500mhz, ondemand manda lo stesso la CPU al massimo (massimo che poniamo a 1,2ghz o 1200mhz, come per il nostro SII). Frequenze più alte hanno voltaggi più alti, quindi è facile intuire che una gestione del genere è sì, buona per la velocità del sistema, ma non lo è altrettanto per il risparmio energetico, fondamentale negli smartphone.

Conservative è una versione rallentata di Ondemand, con gli stessi parametri (modificati nei valori) tranne per down_threshold che gestisce a che percentuale di carico il governor deve abbassare le frequenza.

Il governor Interactive viene spesso considerato un Ondemand più veloce, ma differisce da esso per il fatto che mentre quest'ultimo interroga la CPU ad ogni campionatura di processi, l'Interactive manda la CPU verso l'altro secondo degli intervalli di tempo. Questo lo avvantaggia per il fatto che anche i processi con meno richiesta approfittano della frequenza di clock alta per svolgersi più velocemente ed in un'unica campionatura di intervallo.


Questi 3 governor sono, come detto poco sopra, i capostipiti, quelli dai quali nascono gli altri, che si differenziano da essi per alcuni parametri impostati.

Vediamo dunque i governor basati sull'Ondemand.

• Lagfree è molto simile ad Ondemand, ma vi si differenzia per il fatto che non fa balzare la CPU direttamente alla frequenza più alta, ma passa per tutti gli step in maniera relativamente lenta e si ferma quando il processo è soddisfatto. È comunque performante, ma ha un occhio di riguardo alla batteria.
• Intellimand (o intelligent ondemand) si comporta nella stessa maniera dell'ondemand classico, tranne per il fatto che quando lo schermo è spento, limita la frequenza massima ad un dato valore (imponibile dall'utente), ma quando lo schermo è acceso, si comporta tale e quale all'ondemand.
• OndemandX è simile all'intellimand tranne per il fatto che la data frequenza alla quale lavora la CPU a schermo spento è 500mhz.

Dopo aver analizzato i governor basati sull'ondemand, passiamo alla visione quelli basati sul conservative.

• Molto simile al conservative è il Lionheart che si modifica per quanto riguarda l'aggressività con la quale scala verso l'alto le frequenze, modificando up_threshold
• Cugino del precedente è LionheartX che aggiunge la sospensione del profilo a schermo spento.

Adesso una cernita, la più lunga, di governor basati sull'interactive.

• InteractiveX è identico ad interactive tranne per il fatto che differenzia i profili a schermo acceso e a schermo spento, risparmiando batteria.
• Smartass è molto simile ad interactive, ma è stato totalmente riscritto per fornire una migliore durata della batteria.
• SmartassV2 è la versione migliorata del precedente governor: difatti assegna ai processi un valore accertato in ideal_freq e fa arrivare la CPU a tale valore velocemente senza mandarla per forza ai livelli più alti. Inoltre scala le frequenze verso il basso in maniera più veloce. Molto parsimonioso sulla batteria, ma estremamente performante.
• Lulzactive è uno dei migliori governor: quando il carico della CPU è superiore al 60% fa scalare la frequenza verso l'alto, quando invece è inferiore al 60% la scala verso il basso. Grazie ad una revisione di tale governor, adesso è possibile settare questo valore a piacimento, in modo da bilanciare a seconda delle proprie esigenze, il carico della CPU.
• Lulzactiveq è la versione migliorata del precedente, con l'aggiunta del controllo sull'hotplug ossia della sincronizzazione dei core, cosa che permette al governor di far lavorare i due core (ed i relativi threads) a frequenze differenti.
• Brazilianwax nasce molto simile allo SmartassV2, ma molto più aggressivo, cosa che lo rende scomodo nella gestione energetica.
• SavagedZen è la versione meno aggressiva di Brazilianwax.

Con questo terminiamo la trafila di governor basati su interactive e passiamo a quelli che seguono una logica propria.

• Performance è un governor sul quale non c'è molto da dire se non che la frequenza minima corrisponde alla frequenza massima e non usa altro. Per cui, nel caso di un Galaxy SII, la CPU girerà sempre a 1.2ghz. È da usare solo e soltanto per i test di benchmark.
• Powersave invece blocca la frequenza massima a quella minima e non esistono altri step di frequenza. Sempre citando il GSII, la CPU girerà sempre e solo a 200mhz. Non è consigliato usare questo governor per l'uso quotidiano, ma la notte potrebbe essere un buon compromesso.
• Userspace è il governor della libertà: lascia decidere all'utente quali frequenze settare.
• Pegasusq è un governor introdotto da Samsung con l'uscita del Galaxy S3 ed è particolare per il fatto che ha anch'esso il controllo dinamico sull'hotplug, ossia sulla gestione asincrona dei core, che non lavorano più alla stessa frequenza, bensì si adattano alle frequenze richieste dal sistema in maniera indipendente.
• zzmoove è un governor che si accosta alla logica di Pegasusq, tranne per il fatto che quando il carico è minimo, un core (solitamente cpu1) viene spento e quando il carico è nullo, vengono spenti tutti, 3 nel caso dei quad core e solo 1 nel caso dei dual core (vengono spenti tutti tranne cpu0). Resta comunque il fatto che, a necessità, i core balzano subito alla massima frequenza.

Adesso avete un'infarinatura di base sul funzionamento dei governor e su come incidono nelle prestazioni e nel consumo della batteria. 

Ma non di solo governor vive la CPU, difatti anche la maniera nella quale vengono ordinati ed inviati i processi al governor è fondamentale. Come detto sopra, questo è compito degli Scheduler I/O, e come i governor, ne esistono di diversi.

• Deadline è un cosidetto scheduler in tempo reale, visto che fa eseguire le richieste del sistema nella maniera più veloce possibile. Questo provoca una mancanza di latenza del singolo processo, ma allo stesso tempo, se il sistema è sovraccarico di processi da eseguire, può capitare che un set di processi non viene eseguito.
• Noop segue la logica del "chi ultimo arriva, prima viene eseguito", cosa che fa risparmiare batteria visto che esegue meno cicli. Non è eccezionale, visto che influisce sulle prestazioni negativamente.
• SIO è uno dei più diffuso, è un misto dei due scheduler precedenti e cerca di svolgere i processi il più velocemente possibile, ma senza metterli in ordine alcuno. Ha lo svantaggio di avere una lenta scrittura su dispositivi flash (per cui il collegamento usb ne risente).
• BFQ assegna delle priorità ad ogni processo e quando questo viene eseguito, si passa a quello con maggiore priorità.
• Vr è basato sul BFQ ed è ottimale per i benchmark, solo che soffre di perdite di prestazioni.
• ROW (Read Over Write) migliora l'apertura dei file multimediali ma perde nel trasferimento USB.

Questi sono, infine gli scheduler. Come potete vedere sono diversi e tutti selezionabili in base alle proprie esigenze. Personalmente uso il SIO e, se non disponibile, il ROW, in accoppiata al governor Pegasusq (quando possibile) o allo zzmoove o al lulzactiveq.

Ci stiamo dilungando un po' troppo, per cui spezzo qui questo articolo per rimandare a domani la seconda parte riguardante alcuni chiarimenti su come e perché usare certi governor e su come tweakare i governor già esistenti.

Se siete riusciti a leggere fino a qui, vi faccio i miei complimenti e vi rimando alla successiva parte. 

Alla prossima!