Originariamente inviato da
matteogioia
Fonte Rombusy, Pills of droid.
Come ben sappiamo, quando andiamo ad acquistare un devices, la prima cosa che ci capita di leggere è “SO android 800mhz” oppure 1,5ghz dual core e così via.
Quella altro non è che la frequenza massima del processore che monta il nostro smartphone.
Se esiste la frequenza massima esisterà in egual modo quella minima.
La modalità e la velocità con la quale il processore passa dalla frequenza massima a quella minima viene regolata dal cosiddetto*“governor”.
Per quanto riguarda il governor che è possibile trovare su*android stock, ovvero al momento in cui andiamo a comprare uno smartphone o un tablet, necessariamente sarà quello denominato*“ondemand”; ovvero la frequenza è libera di fare ciò che vuole in base alla potenza richiesta.
Se da un lato il governor ondemand risulta il più equilibrato, dall’altro alcune volte il processore lavora a frequenza più alta di quanto servirebbe, inoltre il governor ondemand permette al processore di raggiungere la massima frequenza nel minor tempo possibile e qui va detto che maggiore velocità nel passaggio dalla frequenza minima a quella massima si traduce in un consumo energetico più elevato. Per ovviare a questo piccolo inconveniente gli sviluppatori si sono inventati una marea di governor per andare incontro a tutte le esigenze. Eccoli riassunti:
ONDEMAND:Governor di default. Grazie ai suoi settaggi bilanciati riesce ad offrire un buon compromesso fra batteria e prestazioni. Non ha però un profilo di sospensione e ha qualche mancanza in prestazioni negli smartphones.
USERSPACE:Permette di impostare manualmente le frequenze. Non è molto usato.
CONSERVATIVE:E’ più lento a raggiungere il 100% rispetto a Ondemand. Per esempio quando si accende il telefono Ondemand alza la frequenza fino al massimo ad una velocità X. Conservative lo fa ad una velocità x/2. Più velocemente si raggiunge il 100% più batteria si consuma quinidi Conservative è peggiore come prestazioni ma migliore come consumi.
PERFORMANCE:Il contrario di Powersave. Imposta la frequenza minima come quella massima quindi il telefono è sempre al 100%. Questo Governor è di solito usato con i profili di*SetCPU*quando il telefono è sotto carica o collegato al PC. Ovviamente non può essere usato come Governor di default.
INTERACTIVE:Mentre Conservative è più lento di Ondemand, Interactive è più veloce. Il raggiungimento del 100% sarà più veloce quindi il telefono risulterà più pronto e veloce; la batteria consumerà un pò di più. Questo Governor è stato il più popolare dell’ultimo anno.
INTERACTIVE-X:Invece di usare*SetCPU*per bloccare la frequenza al minimo quando il telefono è in standby, questo Governor lo fà automaticamente in modo più pulito ed efficente, con una gestione del ramping (aumentare fino al 100%) migliore. Praticamente come l’Interactive ma con una migliore batteria.
SMARTASS:E’ basato su Interactive con alcune modifiche. Anche questo Governor porta la frequenza al minima a telefono in standby. E’ diventato molto popolare nell’ultimo periodo.
SavagedZen:Governor basato su Smartass con modifiche per migliorare sia i consumi che le prestazioni. Molto bilanciato.
MinMax:Un adattamento del Conservative, probabilmente quello con la miglior performance di tutti. L’utilizzo della batteria è maggiore rispetto allo Smartass ma a vantaggio di una maggior velocità del sistema.
SCARY:Basato sul Conservative che ha un Ramping più lento di Ondemand ma prende alcune parti dallo Smartass che ha un ramping molto veloce.
PEGASUS È un governor multicore basato su ondemand. Cerca di far eseguire più processi “contemporaneamente” che risultano attivi in un array ed ai quali vengono fornite priorità al fine di dare le giuste risorse ad ogni processo.
HOTPLUG e HOTPLUG XIl governor hotplug è basato su ondemand con la differenza che i core della cpu vanno offline quando non usati producendo risparmio di batteria. L’hotplug x è invece ottimizzato per ridurre i
consumi a schermo spento.
WHEATLEY:Basato su ondemand, regola il tempo per scalare o aumentare la frequenza in maniera intalligente ed in base alla potenza richiesta dalle operazioni connettendo quindi prestazioni ed autonomia. Ovviamente è solo per i dispositivi multicore.
NIGHTMARE E DARKNESSIl nightmare è un governor disponibile per un particolare tipo di kernel, il Dorimax, quindi non disponibile per tutti i devices. È il risultato di settaggi molto particolari dei processi di sleep/awake e della frequenza della cpu che rendono il device fluido ma allo stesso tempo non pregiudica la durata della batteria, aumentandola. Il darkness è una versione logicamente semplificata del nightmare.
ZZMOVEGovernor ottimizzato per bassi consumi a schermo spento, con particolare attenzione alla limitazione dei consumi delle applicazioni in background a schermo spento come ad esempio ascoltare musica. Possiede tre impostazioni: battery saver, balanced e performance. Inoltre per un boost di prestazioni esiste anche il governor zzmove optimized.Naturalmente non esiste un governor migliore degli altri ma esiste solo quello migliore per se stessi. Tuttavia il più bilanciato e gettonato in questo ultimo periodo risulta l’interactive-x, il quale bilancia perfettamente prestazioni ed autonomia…quale è la vostra esperienza?*
Fonte: Rombusy,Pills of droid
La parola scheduler si traduce letteralmente in “mettere in lista” o “pianificare”. Esso è per l’appunto un programma*sotto forma di 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 parametri, in modo da ottimizzare l’accesso a tale risorsa e consentire così l’espletamento del servizio/istruzione o processo*desiderato.L’attenzione posta su alcuni parametri piuttosto che su altri, differenzia la cosiddetta*politica di scheduling: solitamente lo scheduler può eseguire le richieste in base al loro ordine di arrivo, oppure dare precedenza a quelle che impegnano per meno tempo la risorsa; possono esistere politiche che si basano su principi statistici o sulla predizione per individuare un ordinamento delle richieste che si avvicini il più possibile quello ottimale.
Generalmente l’obiettivo dello scheduling è quello di massimizzare:
il*throughput, ovvero la produttività dell’intero sistema, minimizzando i tempi in cui la risorsa è inutilizzata;
cercare l’ordinamento di richieste che minimizza il rapporto tra tempo di servizio (ovvero il tempo che una richiesta impiega per essere soddisfatta) e tempo di “turnaround” (il lasso di tempo che intercorre tra l’istante in cui la richiesta è generata e quello in cui la richiesta è soddisfatta);
evitare fenomeni indesiderati come la starvation*ovvero “l’attesa eterna” di alcune richieste, verificabile in determinate condizioni;dare all’utilizzatore del sistema la percezione che le richieste vengano soddisfatte contemporaneamente.
Esistono in realtà molti requisiti che possono essere presi in considerazione, dipendenti anche dal problema specifico che lo scheduler deve gestire: esistono schedulers che si occupano di suddividere il tempo di uso del processore da parte di un processo, schedulers che gestisono richieste di lettura/scrittura da una periferica, anche gli algoritmi di sostituzione delle pagine*della memoria sono da considerarsi “scheduler”.
Molti sono gli I/O (input/output) scheduler creati per android e i più conosciuti sono:
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: è 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. Esso risulta lo scheduler di default su cyanogenmod!
BFQ: è 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.
ROW: letteralmente “read over write” ovvero uno scheduler*che fornisce la priorità a tutte le richieste di lettura piuttosto che scrittura. Questo scheduler è stato progettato appositamente per i dispositivi mobili ed è quello che offre una “migliore gestione dei processi” ed influisce molto positivamente sulla durata della batteria.
Insomma,questi piuomeno sono governor e scheduler in grandi linee,spero di avervi aiutato e se così fosse,non esitate a elargire thanks!
PM:Scusate se gli spazi tra alcune sezioni sono diversi,ho fatto questo lavoro tramite cellulare.
LinkBack URL
About LinkBacks
Ultima modifica di h4ck3r00; 27-11-13 alle 21:44
ma penso solo che sia un po' meglio del v1
Originariamente inviato da Tumbler
Ultima modifica di h4ck3r00; 27-11-13 alle 
Rispondi quotando
ma penso solo che sia un po' meglio del v1
