--- GOVERNOR ---
Il Governor è un driver presente nel kernel che permette di regolare la frequenza minima e massima della CPU e il tempo necessario ad essa per raggiungere il massimo o il minimo valore di frequenza di clock del processore, così facendo si vanno a modificare le prestazioni del proprio device nonchè il consumo di batteria.

Purtroppo la scelta del Governor da utilizzare non è una scelta assoluta, ma relativa, infatti bisogna provarli.. e vedere quale funziona meglio sul nostro device, perchè ogni processore è diverso da un'altro (anche a parità di device) e presenta caratteristiche diverse, un governor non adatto può peggiorare le prestazioni..

Nei vari kernel stock, ovvero quelli presenti nel proprio firmware di default (niente cooked o appunto kernel moddatti) i Governor presenti sono di solito sempre gli stessi, e sono:
- Ondemand
- Powersave
- Userspace
- Conservative
-Performance

sui kernel moddati invece i Governor sono molti, e variano di numero in base al lavoro dello sviluppatore, che decide quali inserire o eliminare sul proprio kernel....



GOVERNOR AD OGGI CONOSCIUTI ED USATI:

-- Ondemand --
E' il governor di default in quasi tutti i kernel stock. Uno degli obiettivi principali del gover ondemand è quello di passare alla frequenza max non appena vi è una attività della CPU rilevata per garantire la capacità di risposta del sistema..
..è il più equilibrato, offre un buon compromesso tra consumi e prestazioni.


-- Ondemandx --
Lavora allo stesso modo dell'ondemand, ma con in più un profilo screen off integrato che imposta il clock del processore quando lo schermo è spento alla frequenza massima di 500 mhz.



-- Powersave --
Con Powersave viene impostata sia la frequenza massima che quella minima al minimo valore possibile, anche se è ottimo per i consumi, non è consigliato per l’uso quotidiano, in quanto il processore non riuscirà a raggiungere le frequenze richieste e necessarie per un giusto e godibile uso del vostro device.



-- Userspace --
Userspace consente di impostare manualmente le frequenze. possiamo impostare a nostro piacimento la frequenza minima e massima di lavoro del processore.


-- Intellidemand --
Il nome deriva da "Intelligente Ondemand", questo governor di basa sull'ondemand ma si comporta appunto in maniera intelligente, non non salta mai alla massima frequenza quando lo schermo è spento, e si comporta in modo diverso in base all'utilizzo della GPU.


-- Conservative --
Lavora allo stesso modo dell'Ondemand ma in maniera più lenta e graduale..
quindi Conservative è meno reattivo ma risparmia la batteria.


-- Smartass --
E' basato su Interactive, ma con miglioramenti sostanziali, come ad esempio il mantenimento delle frequenze minime quando il telefono è inattivo.


-- SmartassV2 --
E’ uno smartass modificato ed è uno dei governor più usati. Questo governor mira a una "frequenza ideale", per cui scala in maniera più aggressiva nei confronti di questa frequenza e in maniera meno aggressiva dopo. Esso utilizza diverse frequenze ideali per lo schermo acceso e per lo schermo spento, che sono awake_ideal_freq e sleep_ideal_freq, garantendo così un equilibrio tra prestazioni e durata batteria.


-- Performance --
E' l'opposto di Powersave, e imposta la massima frequenza di clock del processore sia per la minima che per la massima..
.. le prestazioni saranno sempre al massimo, ma la batteria ne risente fortemente... ragion per cui non è indicato per l’utilizzo quotidiano in quanto la batteria si consumerebbe in pochissimo tempo.


-- Interactive --
Lavora allo stesso modo dell'Ondemand ma se in maniera più veloce, quindi maggiori prestazioni , ma anche maggiori consumi di batteria.


-- Interactivex --
E' un Interactive modificato per diminuire il consumo di batteria.


-- Interactivex V2 --
E' l'Interactivex e con lo schermo spento disattiva automaticamente la cpu1.


-- Smoothass --
Si basa sullo Smartass ma con alcune modifiche, infatti presenta una rampa di salita e discesa più pendente (alta), quindi più prestazioni subito ma un minore cosumo di batteria.


-- BrazilianWax --
E' è come lo Smartass ma ha un cambio di frequenza più rapido.


-- SavagedZen --
Altro governor basato sullo Smartass ma con alcune modifiche al fine di ottenere buone prestazioni ma con un consumo non eccessivo della batteria.


-- Scary --
Basato sul Conservative (il quale ha rampa più lenta di Ondemand), ma ha poi in sè alcuno elementi di Smartass che gli permettono di avere una rampa molto veloce.
E' in pratica un misto tra Conservative e Smartass.


-- Minmax --
Basato sul Conservative, viene considerato uno dei migliori, prestazioni e la reattività sono molto elevate..


-- Lulzactive --
Anche questo viene considerato uno dei migliori Governor a disposizione..
E' Basato su interactive e smartass, nel dettaglio il comportaemento del procesore è il seguente:
Quando il carico di lavoro è maggiore o uguale al 60%, fa salire le frequenze della cpu immediatamente allo step successivo... invece quando il carico di lavoro è inferiore al 60%, abbassa immediatamente le frequenze della cpu allo step precedente... se lo schermo è spento, la frequenza è bloccata alla frequenza minima.
utilizzando questo governor possiamo personalizzarne i vari parametri a nostro piacimento tramite l'App .


-- Lazy --
E' in realtà un Ondemand modificato, dove vi è aggiunto il parametro "min_time_state" il quale che stabilisce un tempo minimo in cui la cpu deve rimanere su una determinata frequenza prima di passare alle altre frequenze, base o alte che siano..
..questo per eliminare le instabilità causate dal rapido cambio di frequenza che si ha su ondemand.
Oltre al parametro aggiuntivo "min_time_state" ha anche un parametro "screenoff_maxfreq", che se se attivato farà sì che il processore non superi una frequenza massima pre impostata quando schermo è spento.


-- Lagfree --
E' simile all'Ondemand, ma con la sostanziale differenza che garatisce l'aumento o la diminuizione delle frequenze in maniera graduale, non saltando le frequenze durante la salita o la discesa.


-- Wheatley --
In breve questo governor non è altro che un Ondemand modificato, per avere buone prestazioni ma senza un consumo eccessivo della batteria...
Questo Governor è stato rilasciato da pochissimo tempo ed ancora non è molto diffuso.. se volete approfondire la lettura vi rimando al thread dello sviluppatore


-- Lagfree --
E' simile all'Ondemand, ma con la sostanziale differenza che garatisce l'aumento o la diminuizione delle frequenze in maniera graduale, non saltando le frequenze durante la salita o la discesa.


-- Hotplug --
E' simile all'ondemand, ma scala le frequenze della CPU in base al carico..
Al momento sono riuscito solo a trovare una spiegazione in inglese, vi posto questa in attesa di migliori info più comprensibili e in italiano:
Hotplug Governor:
The "hotplug" governor scales CPU frequency based on load, similar to
"ondemand". It scales up to the highest frequency when "up_threshold"
is crossed and scales down one frequency at a time when "down_threshold"
is crossed. Unlike those governors, target frequencies are determined
by directly accessing the CPUfreq frequency table, instead of taking
some percentage of maximum available frequency.

The key difference in the "hotplug" governor is that it will disable
auxillary CPUs when the system is very idle, and enable them again once
the system becomes busy. This is achieved by averaging load over
multiple sampling periods; if CPUs were online or offlined based on a
single sampling period then thrashing will occur.

Sysfs entries exist for "hotplug_in_sampling_periods" and for
"hotplug_out_sampling_periods" which determine how many consecutive
periods get averaged to determine if auxillery CPUs should be onlined or
offlined. Defaults are 5 periods and 20 periods respectively.
Otherwise the standard sysfs entries you might find for "ondemand" and
"conservative" governors are there.


-- Hotplugx --
E' un Hotplug modificato e ottimizzato per la sospensione in screen-off


-- AbyssPlug --
E' un Governor derivato dall'Hotplug, funziona alla stessa stregua, ma con all'interno delle modifiche per un miglior risparmio della batteria.


-- Pegasusq --
Al momento non sono riuscito a trovare una spiegazione in Italiano, ma una spiegazione in inglese, segnalata dal nostro utente "probie" che ringarazio ancora.... vi posto questa in attesa di migliori info più comprensibili e in italiano:
Let's see what is pegasusq governor which claims to be a multi core aware governor.

Some Basics to Remember Before Reading On:
Some patience is required to understand a governor.
Pegasusq is basically an ondemand based governor which also controls hotplugging.
Run Queue: We know mutiple processes can run at once on our device. These active processes are placed in an array called a run queue along with their priority values. (Priority is used by the task scheduler to determine which process is to run next) To ensure each process has a fair share of resources, each one is run for some time period then paused and placed back into the run queue. When a program is stopped to let another run - the program with the highest priority in the run queue is then allowed to execute.
Talking w.r.t to Android O.S and GS2 CPU, each core is given a run queue, which maintains both an active and expired array of processes. The scheduler selects the next process from the active array with highest priority. When a process' time period expires, it is placed into the expired array with some priority. When the active array contains no more processes, the scheduler swaps the active and expired arrays.
Wall Time is the total up time of CPU. Idle Time is the total idle time of the CPU. The difference (wall time-idle time) gives you the CPU Busy Time. And load on CPU is calculated as percentage of Busy Time on Up Time. (Doesn't it make a lot of sense )
Governor doesn't scale CPU but tells the CPU driver to do so.
Sampling means to evaluate load.
Smooth scaling is also done by CPU driver, not by governor.
Switching to pegasusq will deactivate Stand Hotplug since the governor's hotpluggging logic can conflict with that.
Switching to a different governor from Stand hotplug will re-activate Stand Hotplug since you need a logic to control hotplugging.
Use scripts or SetCpu to change tunables.
Gokhanmoral modified pegasusq (originally authored by Samsung for quad core devices) in Siyah kernel to be dual core friendly.



1) sampling_rate - Measured in uS and actual meaning being Sampling Interval, this factor is used to determine how often the governor should poll for CPU usage in terms of frequency and load percentage to make scaling decisions - either scale CPU Up or scale it Down.

2) up_threshold - Measured as percentage, this is the load on CPU at which governor scales CPU Up. Lower value - early scale up, and viceversa.

3) sampling_down_factor - Acts as a mutiplier to sampling interval for re-evaluating the load when CPU is truly busy and is on highest clock frequency (policy max). Setting to 1 makes no difference and causes CPU to immediately scale down from highest frequency. Sampling down factor is not valid for lower frequencies and low load conditions. Note that CPU is scaled up to max frequency when max_load_freq is greater than up_threshold*current frequency. Max_load_freq is an arbitory frequency calculated as the maximum of load_frequencies. Load_frequency is an arbitrary frequency which describes the frequency the device theoretically needs to handle 100% load, calculated as load*average_frequency.

4) down_differential - After spending sampling_down_factor*sampling_rate micro seconds at maximum frequency on high load, governor samples the load again to calculate an approx target frequency to scale-down-to which should not trigger up_threshold in the next sample. (Triggerin up threshold may cause jumping to max frequency again). Down_differential also act as the factor which prevent agressive scale down. Max_load_freq is checked against (up_threshold - down_differential) * current frequency. If found to be smaller, CPU is scaled down to a target frequency as described above.

5) freq_step - Defines how much as a percentage of maximum frequency, governor should increase CPU frequency each time CPU load reaches up_threshold.

6) cpu_up_rate - No of samples to evaluate load to scale CPU Up. After cpu_up_rate samples are finished for a frequency, CPU scale-Up logic is executed. In other words - before scaling Up, cpu_up_rate*sampling_rate micro seconds are spend at a frequency.

7) cpu_down_rate - No of samples to evaluate load to scale CPU Down. After cpu_down_rate samples are finished for a frequency, CPU scale-Down logic is executed. In other words - before scaling Down, cpu_down_rate*sampling_rate micro seconds are spend at a frequency.

8) hotplug_freq_1_1 - Up threshold frequency to turn second core On, when some other conditions is also met. ie If (minimum frequency greater than or equal to hotplug_freq 1 1 and length of average_runque_minimum greater than hotplug_rq_1_1) Hotplug IN Second Core.

9) hotplug_freq_2_0 - Down threshold frequency to turn second core On, when some other conditions is also met. ie If (maximum frequency less than hotplug_freq 2 0 and length of average_runque__maximum less than or equal to hotplug_rq_2_0) Hotplug OUT Second Core.

10) hotplug_rq_1_1 - Threshold run queue length for second core to turn on.

11) hotplug_rq_2_0 - Threshold run queue length for second core to turn off.

12) ignore_nice_load - Setting to 1 causes governor to ignore load resulted by nice processes while making scaling decisions. Nice processes are the one i/o scheuler refers to as low priority process.

13) io_is_busy - Setting to 1 causes treating i/o wait time as CPU busy time. To imporve performance of heavy applications, set this to 1.

14) max_cpu_lock - Calculated as minimum of (its current value and number of possible cpus). If it has a non-zero value and the value is greater than no of online cores, cancels Hotplugging IN the second core. Leave it as default 0.

15) hotplug_lock - Hotplugging second core is cancelled if it's value is greater than zero. The value should be greater than value of max_cpu_lock. Leave it as 1.

16) cpu_up_freq - Calculated as minimum of (its current value and maximum frequency), this tunable is actually not used by the governor.

17) cpu_down_freq - Calculated as maximum of ( its current value and minimum frequency), this tunable is actually not used by the governor.

18) up_nr_cpus - Calculated as minimum of (its current value and num of possible cpus), this tunable is used by the governor to indirectly make Hotplugging decisions, but may not be useful for a 2 core CPU.

19) dvfs_debug - Set to 1 to enable governor logging. If you're an enthusiast, this may be useful to view the impact of the values for governor tunable set by inspecting the log.

























--- I/O SCHEDULER ---
Lo Scheduler è un algoritmo che, dato un insieme di richieste di accesso ad una risorsa, stabilisce un ordinamento temporale per l'esecuzione di tali richieste, privilegiando quelle che rispettano determinati criteri in modo da ottimizzare l'accesso a tale risorsa.
La differenza tra i vari scheduler è l'attenzione posta su alcuni criteri piuttosto che su altri.
La scelta di un dato scheduler non produce cambiamenti così visibili come per la scelta dei governor, ma apporta comunque dei miglioramenti.
Al solito gli scheduler vanno provati personalmente per trovare quello più adatto alle proprie esigenze.

Deadline
Si prefigge lo scopo di garantire un termine, una scadenza a tutte le richieste in modo da evitare fenomeni indesiderati come lo "starvation" ovvero l'eterna attesa di alcune richieste che si verifica quando uno o più processi di priorità bassa vengono lasciati indefinitamente nella coda dei processi pronti, perchè vi è sempre almeno un processo pronto di priorità più alta.

V(r)
La richiesta successiva viene eseguita in base alla distanza dall'ultima richiesta. In rete girano buoni pareri riguardo questo scheduler.

No-op
Inserisce tutte le richieste in un’unica coda semplicemente in base al loro ordine di arrivo, raggruppando insieme quelle contigue.

SIO
E' lo scheduler più semplice, non fa alcun tipo di ordinamento, si prefigge solo lo scopo di ottenere una bassa latenza, di ridurre cioè il lasso di tempo che intercorre tra l'istante in cui la richiesta è generata e quello in cui la richiesta è soddisfatta.

CFQ
Ordina le richieste dei processi in code distinte per tipologia e assegna a ciascuna coda uno specifico intervallo di tempo la cui durata dipende dalla priorità assegnata ai processi. Può essere considerato l'Ondemand degli scheduler, è infatti lo scheduler più equilibrato, svolgendo il suo compito in maniera onesta.

BFQ
E' basato sul CFQ ma, invece degli intervalli di tempo, assegna una parte della larghezza di banda del disco a ogni processo in esecuzione in modo proporzionale.

Anticipatory
Ordina le richieste in base a criteri predittivi, mette cioè in pausa le richieste per un brevissimo periodo di tempo in previsione che arrivino altre richieste simili in modo da aggregarle.




---------------------------------------------------------------------






Questo thread è stato stilato in base a delle ricerche sul web e alle info recuperate dai vari feed degli utenti, Ringrazio in particolar modo l'utente "dborello" per aver postato molte delle info presenti in questo thread
un ringraziamento anche al nostro grande developer Zeroblaster dal quale ho preso alcune info, ma soprattutto lo spunto per realizzare questo thread








Se avete suggeriementi o consigli postate pure, sarò lieto di aggiungerli ed eventualmente se necessario limare la guida