[GUIDA] [KERNEL MANAGER] Dal Semaphore Script Manager ai segreti dei Kernel

Premesse per la leggibilità

In fondo a questo primo post troverete eventuali file di download, questo thread nasce da una mia spontanea voglia di documentazione sull'argomento dei Kernel e delle loro possibili configurazioni ed è nato dall'occasione particolare dell'utilizzo dello Script Manager v0.42 del Semaphore Kernel 1.8.0beta1, compatibile con JVS e non più distribuito poichè l'autore ha scelto di passare direttamente alla compatibilità con JVT.
Spero d'ispirare in altri la mia stessa curiosità e che in questo thread ognuno possa apportare sempre maggiori conoscenze, mi riservo i primi post per poter riportare nella prima pagina le informazioni ed i concetti assodati più rilevanti.

Ovviamente tutto ciò che riporterò in questa sede è frutto O della mia esperienza diretta O del mio documentarmi in rete presso altre fonti (principalmente XDA e wikipedia inglese o italiana, riassumendo in entrambi i casi per non stendere dei veri e propri trattati), in entrambi i casi, non mi assumo alcuna responsabilità per ciò che potreste decidere di fare con il vostro terminale a seguito di queste letture. In fondo qui siamo tutti un po' dei pionieri e sbagliando s'impara, ognuno a proprie spese.

Punto di partenza

Riprendo qui lo specchietto delle features dello Script Manager che vi trovate insieme al kernel di cui sopra per farne una sorta di indice per i vari approfondimenti. Man mano che avrò tempo e modo di sviluppare degli approfondimenti li tramuterò in link interni a questo thread, sperando di riuscire a tenere tutto all’interno dei post riservati in prima pagina, me ne terrò tre, spero proprio che bastino.
Ovviamente man mano che qualcuno di voi avrà voglia di condividere le sue conoscenze provvederò ad implementare.

- enable_cifs (load cifs module) --> serve a permettere di gestire il mount delle cartelle e l'utilizzo di programmi come Mount Manager -->personalmente non mi serve, uso già root explorer

- enable_conservative (load conservative governor module) --> APPROFONDITO

- enable_deadline (load the deadline I/O scheduler module) --> di default è abilitato il NOOP I/O scheduler, che usa struttura FIFO e velocizza il merge della chiamate di standard input/output, altrimenti si può abilitare il deadline che invece si basa su una struttura più complessa (una sintetica spiegazione è fornita da Umberto1978 qualche post più in basso)

- enable_Kernel_Scheduler (Tweak Kernel Scheduler (Chainfire)) --> APPROFONDITO

- enable_Logger (must reboot) --> non so cosa sia nè a cosa serva, nessuna informazione sul sito

- enable_netfilter (load netfilter modules for firewall or WiFi, USB tethering ) --> è chiaro a cosa serva --> non ne ho necessità per ora, per cui non l’ho ancora testato

- enable_tun (load tun module) --> serve per la VPN --> non ne necessito per ora

-enable_VM_Dirtyness (Tunes I/O buffering (Chainfire)) --> non so cosa sia nè esiste spiegazione sul sito

- Overclocking --> permette di selezionare la frequenza di clock, 1000 è di default, sono disponibili 1100, 1200, 1300 --> per ora non me ne interesso

-Speedmod Colors --> permette di settare i colori, neutral di default, disponibili anche cold e warm --> ancora non l'ho provato

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

Download Semaphore Kernel 1.8.0 beta1 per JVS il Semaphore Script Manager incluso è la versione 0.42

Kernel Scheduler

Lo scheduler è una parte integrata del kernel Linux, è quella imputata a decidere come la potenza disponibile della cpu vada divisa sui processi in esecuzione. Poiché la cpu può lavorare su un solo processo in ogni dato momento, lo scheduler è responsabile dell’assegnazione di questi intervalli tempo per poter eseguire i processi.
Si evince come lo scheduler (insieme ovviamente ad altre cose) giochi un ruolo essenziale nel quanto reattivo un sistema venga percepito dall’utente. Infatti la reattività dipende, tra le altre cose, dal tempo che intercorre dall’input dell’utente al momento in cui effettivamente la cpu gestisce quell’input (ovvero quando il vostro processo/task verrà macinato nei cicli della cpu).

La situazione attuale (CFS e BFS ed alberi)

Lo Standard Linux Kernel usa il cosidetto “Completely Fair Scheduler” (CFS) dall’ottobre del 2007 e sembra essere utile ancora per la maggior parte dei casi (server, home-pc, smartphone…). La novità di questo tipo di Kernel fu nel passaggio dalle vecchie run queues all’utilizzo dei Red-Black Trees. Cioè???
Abbastanza semplice:
- le run queues sono classici array (vettori, serie) di processi in coda ad ognuno dei quali viene assegnato un valore di priorità e vengono ridistribuiti dinamicamente nella coda in base a questi valori dando ovviamente precedenza per l’esecuzione a quelli con priorità più alta. Il difetto di questo sistema è nel fatto che richiede degli intervalli di tempo per l’analisi dello stato di regime di ogni task/processo in esecuzione per valutarne il comportamento, in modo da assegnargli un valore di priorità adeguato per le successive chiamate, lo stesso vale per i processi che richiedono di essere messi in sleep mode o disattivatti. Detto in altre parole: rischia di diventare “lento” (stiamo sempre parlando di frazioni infinitesime di secondo).
- Un RB Tree, o Albero Rosso-Nero (non è del Milan :D ), è un tipo speciale (bilanciato) di albero binario di ricerca, ovvero una struttura che si utilizza per la comparazione dei dati. Non voglio entrare nel dettaglio del suo funzionamento algoritmico e delle sue regole (se siete interessati davvero ditemelo e aggiungerò un paragrafetto), credo sia sufficiente sapere che per come è congeniato viene rafforzata uan sua proprietà critica: il cammino più lungo dal nodo root (il nodo che funge da punto di partenza) a una foglia (un nodo senza nodi figli) è al massimo lungo il doppio del cammino più breve. Quindi le operazioni di ricerca, inserimento o cancellazione richiedono un tempo di esecuzione nel caso peggiore proporzionale all’altezza dell’albero, il chè è traducibile in un’elevata efficienza se paragonata con gli ordinari alberi binari di ricerca.

Dall’agosto 2009 c’è un nuovo concorrente in gioco sulla scena, il cosidetto “Brain Fuck Scheduler” (BFS), e non è uno scherzo! (la curiosità è che lo propone Con Kolivas, ovvero il programmatore del metodo utilizzato precedentemente al CFS con RB Trees, insomma cerca la rivincita :D ). Il suo obbiettivo è di fornire uno scheduler con un algoritmo più semplice, che non richieda aggiustamenti euristici o la modifica di vari parametri per cucire meglio le perfomances su uno specifico carico di calcolo computazionale. Kolivas sostiene che per l’utente medio questi parametri settabili sono difficili da comprendere, specialmente in termini d’interazione gli uni con gli altri. Afferma inoltre che l’utilizzo di quei parametri settabili può spesso avere come risultato un netto miglioramento delle prestazioni su uno specifico target di calcolo, ma al costo di un peggioramento delle prestazioni sui casi generali. Di fatto il BFS è stato progettato per migliorare la reattività sui dispositivi mobili e desktop computer (con meno di 16 cores) basati su “light-NUMA” (non uniform memory access) Linux.
Il BFS non è ancora stato integrato nella linea principale ufficiale dei Linux Kernel, ma è già stato adottato dalla branca principale di Google per Android e viene utilizzato nella Cyanogen.

Laddove non si è dotati di un kernel BFS, che pare essere il top per i dispositivi mobili, ecco che viene in aiuto il settaggio dello scheduler per migliorare qualcosa del nostro povero e bistrattato CFS ;)…sì, stiamo parlando proprio del nostro Tweak!
Nello specifico è possibile modificare il comportamento del CFS scheduler con alcuni parametri che possono essere settati ed applicati durante il runtime e se ne andranno come un soffio nel vento al reboot --> esatto, significa che i parametri che il tweak inietta vengono resettati al reboot e vanno nuovamente inseriti se li si vuole avere di nuovo in funzione, per cui si può sperimentare e se non si è soddisfatti, riavviate et voilà! Come non fosse mai successo nulla. E’ importante precisare una cosa: questo tipo di modifica si sente solo ed esclusivamente se il sistema viene messo a dura prova, ovvero sotto sforzo di carico di diversi processi attivi contemporaneamente…normalmente non noterete praticamente alcuna differenza nella velocità del terminale.
Quindi è una modifica consigliata a chi effettivamente ha esigenza di sfruttare pesantemente il terminale e la sua potenza di calcolo.

I demoniaci governor…

Partiamo da una breve panoramica su cosa sia un governor e quali siano i vari possibili tipi. Uno dei modi migliori per ridurre il consumo di energia e il surriscaldamento del nostro sistema è smanettare la CPUfreq….e che roba è? Tranquilli, ci si riferisce ad essa anche come alla CPU speed scaling, in pratica è la “scatola del cambio” della nostra CPU. La CPUfreq è l’infrastruttura del kernel che implementa la variazione di frequenza della CPU, anche al volo. E’ proprio questa infrastruttura che permette al sistema di viaggiare a velocità di clock ridotte per risparmiare energia. Le regole e le politiche per la gestione della variazione delle frequenze (verso l’alto o verso il basso) così come il “quando” effettuare queste variazioni sono definiti proprio dai CPUfreq Governor. Questo demone definisce le caratteristiche di potenza della nostra CPU di sistema, il chè di fatto influisce sulle performances. Non entro maggiormente nei dettagli perché qui si parla di vera e propria configurazione dell’infrastruttura del kernel; se avete in mente di produrre un vostro kernel modificato, allora chiedete e vi fornirò qualche link con le informazioni che adesso ometterò per non appesantire la trattazione.
Ogni Governor ha il suo preciso ed unico comportamento, il proprio scopo e la propria adattabilità in termini di carichi di lavoro. Adesso andremo a vedere che tipi di Governor esistono (non tutti sono sempre disponibili per ogni kernel) e le loro caratteristiche:
cpufreq_performance
Il governor Performance forza la CPU ad utilizzare la frequenza di clock più elevata possibile. Viene settata staticamente e non cambia mai. Come logico questo tipo di governor non offre alcun beneficio dal punto di vista del risparmio energetico, è consigliabile utilizzarlo solo in casi di diverse ore di pesanti carichi di lavoro e quasi mai momenti di idle (altrimenti il surriscaldamento va’ alle stelle). Non confondetevi, non significa far andare il terminale sempre come una Ferrari, significa fonderlo! Non è una configurazione adatta ai nostri terminali mobili, a meno di particolari e personalissimi casi di elevato stress del sistema, già illustrati poco sopra.
cpufreq_powersave
Il gemello antagonista del precedente: viene settata staticamente senza possibilità di variazione la frequenza di clock più bassa possibile. Massimo risparmio energetico al costo delle minime prestazioni di CPU. Come nel caso precedente, è importante fare delle precisazioni: un CPU lenta (ed è questo il caso) che deve digerire un grosso carico di lavoro consuma MOLTO di più di una cpu veloce non caricata. Ecco perché questo tipo di governor ha senso chiamarlo in causa solo quando si ha la certezza di mettere il sistema in un periodo di inattività completa, poiché qualsiasi picco inaspettato di carico comporterebbe un elevatissimo consumo energetico. A conti fatti sarebbe più corretto pensare a questo governor come ad un limitatore di velocità piuttosto che ad un effettivo “power saver”. E’ consigliato in sistemi dove il surriscaldamento può costituire un problema molto serio.
cpufreq_ondemand
E’ il governor di default del Semaphore. E’ dinamico, consente alla CPU di raggiungere il clock massimo in presenza di carichi elevati e il clock minimo quando il sistema è in idle. Questo permette di tarare il consumo energetico in funzione del carico di sistema ma al costo di una latenza nello switching delle frequenze. Di fatto, questa latenza può vanificare tutti i benefici di prestazioni/risparmio nei consumi offerti dall’ondemand governor se il sistema passa troppo spesso da idle a pieno carico e viceversa. Per la maggior parte dei sistemi l’ondemand governor rappresenta il miglior compromesso tra surriscaldamento, consumo energetico, prestazioni e maneggevolezza.
cpufreq_userspace
Lo Userspace governor permette ai programmi userspace (o qualsiasi processo che è in esecuzione come root) di settarsi da solo la frequenza di clock. Solitamente questo governor si utilizza in congiunzione con il Cpuspeed daemon e chiaramente ne risulta il governor più customizabile; in quanto tale, se configurato correttamente per i propri scopi, può offrire in assoluto il miglior equilibrio tra prestazioni e consumi per il proprio sistema.
cpufreq_conservative
Come l’ondemand governor, anche il conservative governor aggiusta la frequenza di clock in base all’utilizzo. Mentre l’ondemand effettua la cosa in una maniera più aggressiva (dal minimo al massimo e ritorno), il conservative scala tra le frequenze in maniera più graduale. Significa che questo governor porterà il clock ad una frequenza che lui ritiene sufficiente per la soglia di carico rilevata, piuttosto che passare dal minimo al massimo direttamente. Ora, tutto ciò apporterà dei significativi miglioramenti nei consumi energetici, ma al costo di una latenza di switch perfino più grande di quella dell’ondemand. Fate dunque le stesse considerazioni che valevano per l’ondemande per decidere se abilitarlo con lo scriptmanager del Semaphore o meno ;)

*** riservato per futuri approfondimenti due***

*** riservato per futuri approfondimenti tre***

*** riservato per futuri approfondimenti quattro***

Ottima iniziativa Caviglia!
Complimenti.

Innanzitutto GRAZIE per il 3ad, sono un ipercurioso e mi piacciono queste discussioni pionieristiche.
A tal proposito aggiungerei una precisazione, che mi pare d'obbligo:

Cito parzialmente quanto da te riportato "......- enable_deadline (load the deadline I/O scheduler module) --> di default abilita il NOOP I/O scheduler, che usa struttura FIFO e velocizza il merge della chiamate di standard input/output --> mi va bene abilitato poichè ottimizza le prestazioni....."

Mi sono leggermente confuso leggendo, stando almeno alle mie limitate conoscenze.

Lo scheduler NOOP è ritenuto il migliore scheduler per l'impiego con memorie allo stato solido, le cosiddette FLASH, quelle che non hanno funzionamento meccanico o comunque anche parzialmente influenzato da ridondanze o latenze cinetiche; ecco perchè è quello che da migliori prestazioni con terminali mobili. In ogni caso il NOOP utilizza la struttura FIFO, lettelarmente un criterio che si utilizza quasi in ogni aspetto della nostra esistenza anche senza che ce ne accorgiamo: il primo ad entrare è il primo ad uscire (first in first out) un po come avviene alla coda alle poste per intenderci.

Lo scheduler DEADLINE invece a differenza del cugino adotta una struttura differente: impone dei tempi entro i quali devono essere evase le queue; le queue del DEADLINE sono ordinate in base alla loro "expiration time" o data di scadenza ecco perchè il nome deadline. E' evidente che il criterio di assegnazione di tale expiration time non tiene conto necessariamente del momento di creazione della queue ma le valutazioni sono un attimo più complesse, quasi sempre ad esempio nell'impiego di tale scheduler le operazioni di lettura hanno priorità più alta rispetto a quelle di scrittura.

Se ho capito male e detto una cavolata correggimi pure ;)

Quote:

---

Originariamente inviato da umberto1978

Innanzitutto GRAZIE per il 3ad, sono un ipercurioso e mi piacciono queste discussioni pionieristiche.
A tal proposito aggiungerei una precisazione, che mi pare d'obbligo:

Cito parzialmente quanto da te riportato "......- enable_deadline (load the deadline I/O scheduler module) --> di default abilita il NOOP I/O scheduler, che usa struttura FIFO e velocizza il merge della chiamate di standard input/output --> mi va bene abilitato poichè ottimizza le prestazioni....."

Mi sono leggermente confuso leggendo, stando almeno alle mie limitate conoscenze.

Lo scheduler NOOP è ritenuto il migliore scheduler per l'impiego con memorie allo stato solido, le cosiddette FLASH, quelle che non hanno funzionamento meccanico o comunque anche parzialmente influenzato da ridondanze o latenze cinetiche; ecco perchè è quello che da migliori prestazioni con terminali mobili. In ogni caso il NOOP utilizza la struttura FIFO, lettelarmente un criterio che si utilizza quasi in ogni aspetto della nostra esistenza anche senza che ce ne accorgiamo: il primo ad entrare è il primo ad uscire (first in first out) un po come avviene alla coda alle poste per intenderci.

Lo scheduler DEADLINE invece a differenza del cugino adotta una struttura differente: impone dei tempi entro i quali devono essere evase le queue; le queue del DEADLINE sono ordinate in base alla loro "expiration time" o data di scadenza ecco perchè il nome deadline. E' evidente che il criterio di assegnazione di tale expiration time non tiene conto necessariamente del momento di creazione della queue ma le valutazioni sono un attimo più complesse, quasi sempre ad esempio nell'impiego di tale scheduler le operazioni di lettura hanno priorità più alta rispetto a quelle di scrittura.

Se ho capito male e detto una cavolata correggimi pure ;)

---

Nessuna cavolata, quello che dici è corretto e sarà presto soggetto di approfondimento. Quello che intendevo dire (e rileggendomi mi hai fatto capire che poteva essere interpretato all'esatto opposto) è che di default è il NOOP I/O ad essere abilitato nel Semaphore e che quella feature permette invece di abilitare il deadline ;) correggo subito per meglio esprimere la cosa!

Ciao, volevo puntualizzare due cose
Come hai detto tu il Netfilter è evidente a cosa serva, oggi l'ho abilitato per il tethering e ha funzionato alla perfezione.
Per "SpeedMod Colors" si dovrebbero intendere i fix che hardcore ha ideato per il suo kernel chiamato appunto Speedmod, implementati anche su questo. Preferisco però tenerli su Neutral, per poi andare a calibrare lo schermo con VooodoColors (una funzione MAGNIFICA e UTILISSIMA, implementata su pochi kernel).