45
contributi
Patch Con Kolivas: incrementare le prestazioni desktop: differenze tra le versioni
Vai alla navigazione
Vai alla ricerca
Patch Con Kolivas: incrementare le prestazioni desktop (visualizza wikitesto)
Versione delle 08:54, 26 apr 2015
, 26 apr 2015nessun oggetto della modifica
Nessun oggetto della modifica |
|||
| Riga 11: | Riga 11: | ||
Il primo paragrafo di questa guida è dedicato a una breve descrizione del vecchio patchset, con particolare attenzione alle caratteristiche che non son più incluse nel BFS. Il resto della guida spiega come installare e utilizzare le caratteristiche del nuovo scheduler. | Il primo paragrafo di questa guida è dedicato a una breve descrizione del vecchio patchset, con particolare attenzione alle caratteristiche che non son più incluse nel BFS. Il resto della guida spiega come installare e utilizzare le caratteristiche del nuovo scheduler. | ||
== | == Il primo patchset == | ||
;Staircase Deadline Scheduler | |||
Le patch <code>-ck</code> (per il kernel 2.6.21 o successivi) includevano l'innovativo scheduler '''''S'''taircase '''D'''eadline'' (chiamato semplicemente ''SD''). Questo scheduler è l'evoluzione del secondo scheduler dei processi scritto da zero da Con Kolivas (il primo scheduler chiamato ''Staircase'' è stato anch'esso molto innovativo). Le sue caratteristiche principali erano la sua ''fairness'' garantita (tutti i processi della stessa priorità consumano esattamente la stessa CPU) e la sua spiccata ''interattività''. Con Kolivas ha mostrato al mondo per la prima volta che uno scheduler per Linux completamente ''fair'' e con una interattività molto elevata (superiore al mainline) non era solo teoricamente ma anche praticamente possibile. Il vantaggio di un ''fair'' scheduler è la sua assoluta immunità a ''starvation'' che affiggeva lo scheduler mainline (ingosched) e (in misura minore) il vecchio ''Staircase''. | Le patch <code>-ck</code> (per il kernel 2.6.21 o successivi) includevano l'innovativo scheduler '''''S'''taircase '''D'''eadline'' (chiamato semplicemente ''SD''). Questo scheduler è l'evoluzione del secondo scheduler dei processi scritto da zero da Con Kolivas (il primo scheduler chiamato ''Staircase'' è stato anch'esso molto innovativo). Le sue caratteristiche principali erano la sua ''fairness'' garantita (tutti i processi della stessa priorità consumano esattamente la stessa CPU) e la sua spiccata ''interattività''. Con Kolivas ha mostrato al mondo per la prima volta che uno scheduler per Linux completamente ''fair'' e con una interattività molto elevata (superiore al mainline) non era solo teoricamente ma anche praticamente possibile. Il vantaggio di un ''fair'' scheduler è la sua assoluta immunità a ''starvation'' che affiggeva lo scheduler mainline (ingosched) e (in misura minore) il vecchio ''Staircase''. | ||
| Riga 26: | Riga 26: | ||
* [http://lwn.net/Articles/230574/ Schedulers: the plot thickens] | * [http://lwn.net/Articles/230574/ Schedulers: the plot thickens] | ||
<br> | <br> | ||
;Swap prefetching | |||
Altra patch inclusa era la così detta ''swap prefetching''. In pratica questa patch ottimizza l'uso dello swap precaricando delle pagine non appena della RAM risulta disponibile (non quando le pagine sono richieste come sul [[kernel vanilla]]), e questo velocizza notevolmente il passaggio tra le grosse applicazioni se ad esempio se ne chiude una. Inoltre vengono tenute in swap anche pagine caricate in RAM in modo da rendere immediato un successivo ''swap-out''. | Altra patch inclusa era la così detta ''swap prefetching''. In pratica questa patch ottimizza l'uso dello swap precaricando delle pagine non appena della RAM risulta disponibile (non quando le pagine sono richieste come sul [[kernel vanilla]]), e questo velocizza notevolmente il passaggio tra le grosse applicazioni se ad esempio se ne chiude una. Inoltre vengono tenute in swap anche pagine caricate in RAM in modo da rendere immediato un successivo ''swap-out''. | ||
Con questa patch l'utilizzo apparente dello swap sarà maggiore ma in realtà questo è dovuto alle ottimizzazioni fatte per incrementare le prestazioni. | Con questa patch l'utilizzo apparente dello swap sarà maggiore ma in realtà questo è dovuto alle ottimizzazioni fatte per incrementare le prestazioni. | ||
== Lo scheduler BFS == | |||
=== Confronto tra BFS e Mainline=== | |||
Una delle caratteristiche importanti per uno scheduler di processi è la scalabilità; ad esempio se si aggiungono dei processori ad un sistema si richiede che il throughput aumenti in modo significativo ogni volta che viene aggiunto un nuovo processore, anche quando il loro numero diventa molto elevato. <br/> | |||
Altre due caratteristiche desiderabili sono una buona reattività e la fairness (i processi vengono eseguiti secondo la loro priorità e a quelli con uguale priorità viene assegnata la stessa quota di cpu ). <br/> | |||
L'attuale scheduler mainline (CFS) è stato pensato per ottenere buoni risultati in tutte queste caratteristiche: tuttavia per mantenere una buona scalabilità e garantire la fairness sono necessari complessi algoritmi di bilanciamento che deteriorano la reattività e il throughput. | |||
La particolarità del BFS è che è stato progettato con l'unico obbiettivo di ottenere una spiccata reattività e basse latenze nell'uso desktop, senza preoccuparsi minimanente della scalabilità. <br/> | |||
Lo scheduler pesca i processi da una unica coda globale in base alla priorità e alla deadline: questa semplice struttura garantisce la fairness senza bisogno di alcun algoritmo di bilanciamento, tutto a vantaggio della reattività e del throughput. | |||
In sostanza il CFS è uno scheduler progettato per essere adatto a diversi utilizzi, dal desktop al server, (e di conseguenza non ottimizzato per nessuno di essi), mentre all'opposto il BFS si caratterizza come uno scheduler pensato e ottimizzato per un solo utilizzo, il desktop. | |||
===Limiti e particolarità del BFS=== | |||
Prima di applicare la patch conviene valutare se questo scheduler è adatto all'hardware che si possiede e all'uso che si intende fare del proprio pc: | |||
; Scalabilità | |||
Il principale limite del BFS è la scalabilità: secondo alcuni test effettuati questo scheduler comincerà ad avere performance esponenzialmente decrescente sulle CPU con oltre 16 core, mentre al di sotto di questo numero ha una scalabilità anche migliore del CFS. | |||
Notare che ai fini del calcolo del numero di core, contano i core logici e non quelli fisici (quindi una cpu 8 core con HT conterà come 16). <br/> | |||
Un altro caso in cui il BFS potrebbe sotto-performare rispetto al mainline è quello di un pc costantemente sottoposto ad un elevato carico, ad esempio un server che deve eseguire un numero molto elevato di processi che si susseguono tra i loro. | |||
; Overhead e jobservers | |||
La mancanza di algoritmi per la scalabilità rende il BFS uno scheduler a basso overhead, una caratteristica che può essere molto utile con processori a basso consumo come quelli dei cellulari. <br/> | |||
Un'altra situazione dove il basso overhead del BFS risulta vantaggioso è quando si compila del software usando l'opzione -j di make: di solito si usa -jn con n superiore al numero di core del processore, per esempio -j6 su un quad-core. Tuttavia col BFS usare -j4 su un processore quad-core è la scelta più veloce di qualsiasi altro numero scelto con lo scheduler mainline. <br/> | |||
Di fatto lo scheduler mainline non riesce a sfruttare appieno le potenzialità della cpu nelle situazioni più comuni su un desktop. | |||
; Cgroups e systemd | |||
A causa di alcuni bug che si sono verificati nel periodo iniziale di sviluppo di systemd si è sparsa la leggenda che le patch BFS non sono compatibili col nuovo sistema di init. Questo non è vero, nel senso che è possibile usare un kernel patchato BFS e avviarlo con systemd; quello che è vero è che il BFS non implementa i CGROUPS e dunque non sarà possibile esercitare questo tipo di controllo sui processi utilizzando la apposita funzione di systemd. | |||
Poco male perchè le patch introducono un altro semplice strumento, descritto in seguito, per limitare l'utilizzo della cpu da parte dei processi. | |||
; Misurazione della performance | |||
Se utilizzando la patch BFS notate dei valori di carico di cpu anomali, niente paura, almeno finchè il pc risponde ai comandi: infatti bisogna tenere conto che i due scheduler utilizzano un sistema di misurazione del carico della cpu differente e quindi i risultati non sono comparabili con quelli del mainline. | |||
In particolare il CFS utilizza il <code>timer frequency</code> mentre il BFS utilizza <code>l'orologio TSC</code>, che è più accurato per i singoli processi ma può dare misurazioni del carico complessivo "sballate". | |||
Se si vuole confrontare l'efficienza dei due scheduler nell'eseguire un certo lavoro conviene farlo basandosi sul tempo di esecuzione, ad esempio utilizzando il programma <code>time</code>. | |||
=== Nuove priorità: SCHED_ISO, SCHED_IDLEPRIO === | === Nuove priorità: SCHED_ISO, SCHED_IDLEPRIO === | ||