[Kernel Governors] [Modules] [I/O Schedulers] [CPU Tweaks]

[Roydroid]

Tale thread, vuole essere un punto di riferimento per gli esperti Smanettoni e per quelli che, per la prima volta, entrano nel mondo del modding spinto su Android.
Sconsigliamo di eseguire queste modifiche se non si è consapevoli di ciò che si sta facendo; pena il Brick
il thread è ancora in costruzione e se avete materiale da segnalare fate pure.

Crediti
Thread originario qui
BlackJack2 per il supporto e l'aiuto nel realizzare e riorganizzare il thread

PROGRESSIONE DEI LAVORI :
---18:22 14-09-12 creato il thread
---16:25 15/09/12 aggiunti dettagli sui governor
---17:00 17/09/12 aggiunti i tweacks
---15:44 20/09/12 aggiunta guida agli script
---16:22 20/09/12 aggiunti degli I/O scheduler (a breve verranno aggiunti tutti)
---13:04 23/09/12 aggiunti tutti I/O scheduler
---13:08 24/09/12 aggiunta definizione di governor
---13:52 24/09/12 corretti errori al interno del thread, grazie a blackjack2

Governor

Il Governor è simile ad un driver che regola la frequenza minima e massima della CPU ed il tempo necessario ad essa per raggiungere il massimo o il minimo valore di frequenza di clock.

I governor che prenderemo in considerazione sono 18 (sappiate che non vengono mai utilizzati tutti nello stesso kernel eccetto vari casi):
1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) Interactivex
6) Lulzactive
7) Smartass
8) SmartassV2
9) Intellidemand
10) Lazy
11) Lagfree
12) Lionheart
13) LionheartX
14) Brazilianwax
15) SavagedZen
16) Userspacce
17) Powersave
18) Performance

Descrizioni :

Ondemand : governor di default in moltissimi stock kernel ,la sua caratteristica è portare al massimo la CPU appena rileva un processo della stessa in modo da garantire la massima fluidità.
Mano a mano che il carico della CPU diminuisce il governor ne abbassa la frequenza, tuttavia questo governor ha dei lati negativi , ovvero non si sa mai il reale carico della CPU in quanto essendo portata sempre al massimo non si puo avere una vera e propria corripondenza , non è battery friendly pechè come ribadito la CPU ha un obbligo di risposta immediato e anche la minima attività la porta al massimo della potenza.

Ondemandx : praticamente un Ondemed con suspend/wake come profilo. Il governor è un Ondemed battery friendly.
Quando lo schermo è spento la frequenza massima consentita arriva a 500 mhz . Nonostante Ondemed sia lo “stock” molti estendono la compatibilità ad Ondemedx in quanto considerato veloce stabile e sicuro.
Le performance di questi due governor variano profondamente dai i/o schedulers scelti , e questo non capita per il resto dei governor

Conservative: Un Ondemand più lento che sala più lentamente le frequenze per risparmiare batteria. Questo governor di basa sull'Ondemed e regola dinamicamente le frequenze come quest'ultimo, tuttavia le scala più lentamente in modo da dare alla CPU il minor carico possibile e riportarla il più rapidamente alla frequenza più bassa

Interactive : si puo considerare un Ondemand più veloce e con meno richiesta di batteria, scala le frequeze in modo molto veloce, ma cerca di tenere il carico della CPU sempre al minimo. In più la priorità dello scalo della CPU è molto più reattivo rispetto agli altri governor e ciò ne garantisce la fluidità

Interactivex : è il governor interactive con un profilo wake, molto più battery friendly dell'interactive

Lulzactive : Nuovo governor da Tegrak basato su smartass e interactive. Quando il carico di lavoro è superiore o uguale al 60% si scala una frequenza mentre se è inferiore al 60% si torna a quella precedente. Nella nuova versione sono modificabili i paramentri inc_cpu_load, *******_step, pump_down_step e questo permette all'utente di personalizzare a che carico di lavoro scalare e se saltare delle frequenze.

Smartass : Creato da Erasmux che ha riscritto interamente il codice dell'interactive. L'obbiettivo principale è quello di aumentare la durata della batteria senza ridurre le prestazioni. Tuttavia lo smartrass v2 è molto meglio

SmartassV2 : seconda versione dello Smartass , scala le frequenze in modo aggressivo per poi farle dimiuire dolcemente, ha diversi livelli di frequenze a schermo acceso o spento. Il limite non va oltre i 500 mhz garantendo così un perfetto deep sleep , è uno dei miglio rsul “mercato”

Intellidemand : Governor creato da Faux che si basa sull'Ondemend, (si chiama anche Ondemend intelligente) si comporta in modo diverso a seconda del carico della GPU , se la GPU è occupata si comporta come Ondemend mentre se è libera/moderatamente occupata entra in modalità di navigazione ovvero limita la frequanza massima a seconda delle frequenze presenti nel kernel per risparmiare batteria

Lazy :è un Ondemand “pigro” nel senso che si sofferma molto più tempo su ogni frequenza prima di scalare in modo da evitare instabilità, per il resto si conmporta come ondemend

Lagfree : E' un Ondemand che scala tutte le frequenze e quindi è più battery friendly, segnalo che se ce uno sforzo improvviso il governor laggerà un po ( contraddicendo il suo nome ) dato che deve scalare tutte le frequenze.

Lionheart : un governor basato su uno stock samsung con dei tweak aggiuntivi , scala in modo molto aggressivo a discapito della batteria, ha dei parametri sintonizzabili

LionheartX : ha dei parametri sintonizzabili in più e un profilo di smartass

Brazilianwax : uno smartass che scala in modo più aggressivo sacrificando la batteria per le prestazioni

SavagedZen : basato su smartassv2 , ha un buon compromesso batteria/prestazioni

Userspacce : invece di determinare le frequenze le fa impostare all'utente

Powersave : blocca la frequenza massima e quella minima , non si puo usare a schermo spento se il blocco alla minima è troppo alto

Performance : setti la frequenza massima e quella minima...e usi solo quelle !!

[Roydroid]

PARAMETRI GOVERNOR

Governor diversi hanno tweaks e parametri diversi , ma in generale un governor è composto da :

Sampling Time/Rate (frequenza di campionamento) : è la funzione che permette al governor che frequenze scalare e in che circostanze farlo (governor diversi hanno comportamenti diversi).preciso che più alti sono i valori sono alti meno frequentemente scala la cpu.

Thresholds : quando il carico della CPU raggiunge questo punto il governor scala verso l'alto o il basso , naturalmente ci sono due soglie; una di scalo in su e una in giù ( questo valore si minura in percentuale).ricordo che più questo valore è alto e meno è reattiva la CPU

ecco altri parametri che potrete trovare nei vari governor come:

ONDEMED

powersave_bias: il valore di di default è zero ma se si alza il valore si spinge il governor a prendere in considerazione sempre meno le altre frequenze, è un alternativa all'underclocking

sampling_down_factor le frequenze più elevate vengono raggiunte quando la CPU è veramente occupata,il passaggio nelle basse frequenze è molto rapido

down_differential questo valore serve a determinare la frequenza minima del governor Ondemed prende in considerazione la tempistica di scalo in caso di lavoro improvviso andando così ad integrarsi con il pawer save

LULZACTIVE

vecchia versione

down_sampling_time:tempo di scalo della CPU verso il basso
up_sampling_time: tempo di scalo della CPU verso l'alto

il nuovo ha gli stessi del vecchio con qualche novità
nuova versione

inc_cpu_load: permette di scegliere la percentuale di utilizzo della CPU che porterà allo scalo delle frequenze
*******_step: quando carica non scala in su
pump_down_step:quando carica non scala in giù
screen_off_min_step: setti la frequenza da tenere a schermo spento

SMARTASSV2

awake_ideal_freq: scalo aggressivo della frequenza e scalo in basso molto rapido (deep sleep)
sleep_ideal_freq: scala in modo molto aggressivo verso il basso in modo da garantire un perfetto deep sleep
up_rate_us:tempo molto breve perchè la CPU scali all'insù
down_rate_us:tempo brevissimo di scalo alle frequenze più basse
max_cpu_load: come up_threshold degli altri governor
min_cpu_load: come down_threshold negli altri governor
ramp_down_step: appena il governonr ne ha possibilità scala al disotto della frequenza ideale
ramp_up_step: appena il governor ne ha possibilità fa salire la CPU
sleep_wakeup_freq: va il più rapidamente possibile alla frequenza ideale al deep sleep

CONSERVATIVE:

down_threshold, up_threshold, sampling_down_factor, sampling_rate: come negli altri governor
freq_step:in necessita la CPU viene scalata di qualche frequenza

INTERACTIVE

hispeed_freq:scala il più rapidamente possibile
go_hispeed_load:quando il dispositivo è in carica la CPU viene portata al massimo
min_sample_time: fa passare un lasso di tempo prima di diminuire le frequenze
timer_rate:regoli il timer di scalo frequenza

[Roydroid]

GUIDA AI TWEAKS

ecco come/dove inserire gli script nei governor,dato che molte persone non sanno cosa farci (sconsiglio hai n00b) la maggior parte dei costum kernel supportano gli scripts init.d , e sono posti nel percorso /system/etc/init.d directory (oppure /etc/init.d which is a symbolic link to /system/etc/init.d). Molti sono contrassegnati con il codice ASCII ovvero Ascript1, Bscript2 ecc.., Ascript1 avrà una priorità sul seconto.

GUIDA:
1) la prima riga di ogni script deve essere richiamabile ad una shell compatibile, usate busybox
---esempio #!/sbin/busybox sh oppure #!/system/xbin/busybox sh
2)ora iniziamo con lo script
--- echo "200000" > /sys/devices/system/cpu/spu0cpufreq/scaling_max_freq
3)controllate che non ci siano ne errori di indirizzamento ne logici, non usate editor nativi di windows perchè tendono ad inserire dei caratteri automatici che generano errori, consiglio notepad++
4) compilato lo script come volete e salvatelo in estensione .sh
5) inserite il dile con root expolrer in /etc/init.d e settate i permessi (a breve guida su SDK)
---owner : rwx, group : r_x, others : r_x
6)scaricate script menager (root) , controlla gli errori negli script, se riporta come risultato 0 è tutto giusto, gli script partiranno in automatico e il telefono si riavvierà

Esempio di script funzionante :

#!/sbin/busybox sh

#No of values echoed to freq table and uvmv table should match the no of steps in your kernel
echo "1600 1400 1200 1000 800 500 200 100" > /sys/devices/system/cpu/cpu0/cpufreq/freq_table
echo "1425 1325 1275 1175 1075 975 950 950"> /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
echo "200" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo "1200" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo "ondemandx" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

GOVERNOR TWEAKS

Per Ondemed

ecco un tweak per risparmiare batteria:

in questo modo il governor scala la CPU meno spesso

echo "95" /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo "120000" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
echo "1" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo "5" > /sys/devices/system/cpu/cpufreq/ondemand/down_differential

Eccome uno performante invece:

controlla più spesso i valori della CPU e scala più velocemente

echo "70" > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo "50000" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
echo "2" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo "15" > /sys/devices/system/cpu/cpufreq/ondemand/down_differential

Per lulzative

un tweak per aumentare la durata della batteria :

fa scalare più velocemente verso il basso la CPU

echo "90" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/*******_step
echo "2" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "50000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step

Tweak performate :

la CPU scala più velocemente e raggiunge i livelli più bassi lentamente

echo "60" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "4" > /sys/devices/system/cpu/cpufreq/lulzactive/*******_step
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "10000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "70000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step

compromesso batteria prestazioni :

scala molto rapidamente i passaggi ma solo al 90% del carico

echo "90" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "4" > /sys/devices/system/cpu/cpufreq/lulzactive/*******_step
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "10000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step

Tweak per SMARTASSV2

batteria :

echo "500000" > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq;
echo "500000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq
echo "85" > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load;
echo "70" > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step;
echo "48000" > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo "49000" > /sys/devices/system/cpu/cpufreq/smartass/down_rate_us

prestazioni :

echo "800000" > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq;
echo "800000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq
echo "75" > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load;
echo "45" > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load;
echo "0" > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step;
echo "0" > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step;
echo "24000" > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo "99000" > /sys/devices/system/cpu/cpufreq/smartass/down_rate_us

tweack per il conservative ( è possibile ma sconsigliato modificare questo governor per farlo diventare più performante o tenere altra batteria perchè è un governor che serve a mantenere il telefono alla minima attività)

batteria:

echo "95" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo "120000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
echo "1" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
echo "40" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo "10" > /sys/devices/system/cpu/cpufreq/conservative/freq_step

prestazioni :

echo "60" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo "40000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
echo "5" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
echo "20" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo "25" > /sys/devices/system/cpu/cpufreq/conservative/freq_step

Tweack per interactive :


batteria :

echo "95" > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load
echo "1000000" > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
echo "10000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate

prestazioni:

echo "80" > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load
echo "1400000" > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo "20000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate

[Roydroid]

I/O SCHEDULERS

ecco gli I/O schedulers :

1) noop: elenca tutte le I/O in arrivo seguendo la tipologia last in frist out (l'informazione che arriva per ultima esce per prima). consigliato sui dispositivi che non hanno una accesso meccanico hai dati , ad esempio nelle unità flash

Pro : minor numero di clock CPU (la batteria dura qualcosina di più) ,ottima per i dispositivi flash , buona gestione delle informazioni di input

Contro: minor clock = minor prestazioni

2) Deadline: riduce al minimo la latenza degli I/O , vengono usate 5 code e gli I/O vengono aggressivamente smistati li dentro

Pro:riduce la latenza I/O, moto reattivo ,miglior pianificazione di accesso al database, , si necessità di minor CPU, ottima anche questa per i flash

Contro:Quando il terminale è sovraccarico per via di troppi processi il terminale diventa ingestibile

3) CFQ : completamente Fair Queuning, mantiene scalabili i valori dell'I/O e modifica la "coda" a seconda della richiesta di lavoro. Ogni pre-processo ha dei codici che lo scincronizzano al processo vero e proprio. Il tempo che alloca dipende dalla quantità e dalla priorità dei processi simili. La versione due del covernor contiene dei fix che migliornano la capacità di risposta dello scheduler.

Pro: offre ottime prestazioni, facile da calibrare/regolare, ottimo per i sistemi multiprocessore, migliora le prestazioni del database se usato a lungo termina

Contro: la scansiode di dispositivi esterni ecc.. impiega un po più tempo , questo è dovuto alla largezza della basda e dell'equa distribuzione dei processi dei governor

4) BFQ: questo scheduler è basato sul bilanciamento , bilancia tutti i processi a seconda delle esigenze del sistema. Quando il "valore di bilanciamento" scade perchè il compito si è svolto ne viene assegnato subito un altro ( bilancia i valori di sola scrittura in questo caso).

Pro: ottima velocità di trasferimento USB,miglior scheduler per il registrazione hd e video stereaming, 30% più veloce di CFQ

Contro: la pianificazione per il benchmarking non è un granchè , se assegna troppa priorità ad un processo si avranno scatti e lag

5) SIO: tiene un valore minimo come tetto per evitare lag . le richieste degli I/O vengono soddisfatte molto rapidamente. Non concepisce nessuna priorità ma fa un lavoro standard. E' un miscuglio tra noop & deadline e non riordina le richieste.

Pro:semplice e molto affidabile , non stravolge le richieste

Contro:,in generale non è idelale per le unità flash

6) V(R): le richieste sincroniche o asincroniche sono gestite allo stesso modo , il prossimo ordine si stabilisce a seconda della vicinanza con quello appena eseguito

Pro: miglior pianificazione benchmarking che funziona veramente in modo ottimale quando viene raggiunta la massima potenza dello scheduler

Conro: fluttuazione dei valori al disotto della media, molte volte poco affidabile e instabile

7) Anticipatory: Disk seeks molto lento e le operazioni di scrittura possono esserci sempre ma di solito i processi sono abbastanza impegnati. Prevede operazioni sincrone.

Pro: processi mai troppo "affamati", buono come noop per il read-performance nei dispositivi flash

Conro:velocità ridotta su dischi ad alte prestazioni

[Roydroid]

e fui rapito da quest'ultimo

[BlackJack89]

Eccomi
Al Suo servizio

[BlackJack89]

Bene, questo mio, dovrei tradurre questo 3. MODULES

[BlackJack89]

Mio anche questo

[markusssss]

grande topic! lo cercavo da tempo..

Inviato dal mio Galaxy Nexus

[Roydroid]

Grazie sono contento che ti piaccia , a breve lo aggiorneremo

Inviato dal mio GT-I9001 con Tapatalk 2