Patch Con Kolivas: incrementare le prestazioni desktop

Guida adottata da Ombra

Attenzione: questo articolo è ancora incompleto e in fase di scrittura da parte del suo autore. Sentitevi liberi di contribuire, proponendo modifiche alla guida tramite l'apposita pagina di discussione, in modo da non interferire con il lavoro portato avanti sulla voce. Per altre informazioni si rimanda al template.

Versioni Compatibili ERRORE: utilizzare "unstable_2024" come parametro al posto di " Sid "! Vedi qui.

Introduzione

Le patch Con Kolivas (-ck) per il kernel di Linux sono una serie di patch pensate per incrementare le prestazioni desktop, principalmente tramite l'implementazione di uno scheduler in grado di offrire latenze molto basse.
Il primo patchset ha introdotto l'uso di uno scheduler innovativo (staircase), ottimizzando l'uso dello swap (swap-prefetching) e del sotto-sistema disco, e aggiungendo dei nuovi livelli di priorità al di fuori di quelli tradizionalmente impostabili con nice.
L'ultima di queste patch è stata sviluppata per il kernel 2.6.22. Dopo questa versione l'amareggiato Con Kolivas ha abbandonato lo sviluppo della patch a causa di dissidi con altri sviluppatori del kernel.
Parte del design del ck è stato comunque inserito nel kernel mainline con la creazione di un nuovo scheduler, il CFS, che ha rimpiazzato il vecchio.
Dopo qualche anno di inattività Con Kolivas, dicendosi insoddisfatto dalle prestazioni offerte dal CFS, ha ripreso lo sviluppo di un nuovo patchset; questo patchset, tutt'ora mantenuto da CK, utilizza un nuovo scheduler a bassa latenza, il BFS, pensato principalmente per un uso desktop.
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 -ck (per il kernel 2.6.21 o successivi) includevano l'innovativo scheduler Staircase Deadline (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.

Per maggiori dettagli tecnici su SD:

• Con Kolivas Wiki: SD

Per un po' di storia sulla nascita, l'evoluzione e sulla competizione con un nuovo scheduler scritto da Ingo Molnar (CFS) inspirato dal successo di SD potete leggere:

• The Rotating Staircase Deadline Scheduler
• RSDL hits a snag
• Schedulers: the plot thickens

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.

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.
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 ).
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à.
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).
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.
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.
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 timer frequency mentre il BFS utilizza l'orologio TSC, 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 time.

Nuove priorità: SCHED_ISO, SCHED_IDLEPRIO

Normalmente i processi in Linux hanno priorità SCHED_NORMAL. I processi di questa classe possono avere un nice da 19 a -20 che indica la loro priorità all'interno della classe SCHED_NORMAL. Ma su Linux sono presenti altre classi di priorità:

SCHED_NORMAL

questa è, se non diversamente specificato, la priorità dei processi in Linux. I processi di questa classe possono avere un nice da 19 (minima) a -20 (massima) che indica la loro priorità all'interno della classe SCHED_NORMAL

SCHED_BATCH

questa priorità è stata introdotta dal kernel 2.6.16 e viene usata per processi non interattivi (batch). I processi di questa classe avranno priorità inferiore a qualsiasi processo SCHED_NORMAL.

SCHED_FIFO

usata per processi realtime. Un processo SCHED_FIFO avrà priorità superiore ad ogni altro processo (anche SCHED_NORMAL con nice -20). Normalmente processi con tali privilegi possono essere lanciati solo da root: non c'è limite di tempo all'impegno della CPU da parte di questi processi che possono rimanere in esecuzione fin quando un processo con priorità più alta non assume il controllo della CPU. In questo caso il processo che perde il controllo si posiziona in cima alla lista dei processi in attesa (FIFO) con la stessa priorità. I processi all'interno di questa classe possono avere una priorità statica da 0 (minima) a 99 (massima).
Bisogna fare attenzione se si utilizzano processi di questo tipo: infatti, in base al funzionamento appena descritto, lanciando un processo FIFO con massima priorità, può accadere di vedere esclusi tutti gli altri processi (inclusa la propria shell) dall'utilizzo della cpu.

SCHED_RR

usata anch'essa per processi realtime. Questa politica di priorità funziona in maniera simile a SCHED_FIFO ma è di tipo Round Robin anziché FIFO. In pratica ai processi schedulati con questa politica viene assegnato un intervallo di tempo (Time Quantum) durante il quale il processo impegna la CPU. Scaduto il tempo, il processo viene messo in coda alla lista dei processi eseguibili con la sua stessa priorità. Il vantaggio di questa policy rispetto alla precedente è che RR è meno soggetta al problema della starvation, situazione in cui gran parte delle risorse sono dedicate a un solo processo, rallentando o bloccando l'esecuzione di tutti gli altri.

Le patch -ck introducono due ulteriori livelli:

SCHED_ISO

questa è la priorità chiamata soft realtime. Infatti i processi di questa classe avranno priorità superiore ai processi SCHED_NORMAL ma non sono necessari i privilegi di root per eseguire programmi con questa priorità. Potremmo impostare ad esempio il nostro player audio preferito su SCHED_ISO, e non importa quanto sia carico il sistema non avremo mai salti nell'audio. Se si eseguono contemporaneamente più processi SCHED_ISO, questi si alterneranno seguendo una politica di tipo Round-Robin, in modo da evitare il problema della starvation.

SCHED_IDLEPRIO

questa classe di processi viene eseguita solo quando il processore è in IDLE. L'idea è quella di consentire l'esecuzione in background di task a priorità molto bassa, senza alcun impatto sugli altri processi avviati dall'utente. Potremo lanciare compilazioni di kernel, aggiornamenti di sistema, pesanti cron jobs usando questa priorità e non noteremo il benché minimo degrado delle prestazioni durante il nostro utilizzo interattivo. In alcuni casi particolari (sospensione in ram, processo in attesa di I/O, ecc) lo scheduler è in grado di riassegnare temporaneamente a questi processi la priorità SCHED_NORMAL, in modo da evitare che le risorse di sistema siano utilizzate senza limiti di tempo e in modo indesiderato.

Installazione

Nota per una migliore comprensione delle procedure che seguono, fate rifermineto la guida sul kernel alla debian-way

Prima di procedere è necessario installare alcuni pacchetti:

 # apt-get install module-init-tools kernel-package libncurses5-dev fakeroot lrzip schedtool time 

gli ultimi due pacchetti sono opzionali, anche se senza schedtool non potremmo usare gran parte delle potenzialità offerte dalle patch, mentre per quanto riguarda time, è utile solo se si vuole misurare la performance.

La patch -ck più recente può essere scaricata dal sito di Con Kolivas, al seguente indirizzo:

• http://users.on.net/~ckolivas/kernel/

Sulla stessa pagina troverete il link per scaricare i sorgenti del kernel vanilla.
Se la vostra Debian utilizza una versione precedente rispetto all'ultima release, potrete trovare la patch qui, mentre i sorgenti da patchare dovrete cercarli tra gli archivi di kernel.org. Attualmente l'ultimo patch set -ck è il 4.0-ck1, ed il file patch da scaricare è patch-4.0-ck1.lrz . Di seguito si userà, come esempio, il kernel 4.0 e le patch -ck1 per tale kernel.

Spostate i due archivi appena scaricati in una directory nella nostra home, ad esempio in ~/src/ e scompattate i sorgenti

$ cd ~/src/
$ tar -xvf linux-4.0.tar.xz

Una volta scompattati i sorgenti possiamo applicare la patch con:

$ cd linux-4.0
$ lrzcat ../patch-4.0-ck1.lrz | patch -p1

Per una questione di ordine conviene rinominare la directory dei sorgenti in modo da rispecchiare la patch usata:

$ cd ../
$ mv linux-4.0 linux-4.0-ck1

Per la configurazione, la strada più semplice è quella di copiare la configurazione funzionante di un kernel di versione simile a quello che state per compilare, ad esempio

 $ cd linux-4.0-ck1
 $ cp /boot/config-3.16.0-4-amd64 .
 $ make oldconfig 

Rispetto ai kernel standard la patch cambia alcune risposte predefinite in modo da ottenere un sistema adatto a un uso Desktop con bassa latenza, quindi, a meno che non abbiate diverse esigenze, potete lasciare tutte le risposte di default e passare alla compilazione. Se siete interessati qui trovate alcuni suggerimenti per configurazioni da abbinare al BFS, a seconda del tipo di computer e dell'uso che si intende farne.

Una volta terminata la configurazione è possibile compilare il kernel, ovviamente alla debian-way. Se abbiamo già in esecuzione un kernel -ck possiamo lanciare la compilazione in modalità SCHED_IDLEPRIO:

 $ schedtool -D -e time fakeroot make-kpkg --append-to-version -desktop --revision 0.1 kernel_image

In questo modo non ci accorgeremo nemmeno della compilazione durante il normale utilizzo interattivo del computer, infatti la compilazione avverrà solo quando la CPU sarà in idle. Il tempo di compilazione aumenta in maniera impercettibile. Verrà anche stampata la durata della compilazione grazie al comando time.

Se non abbiamo un kernel -ck potremo comunque usare la modalità SCHED_BATCH, cambiando semplicemente l'opzione -D con -B. In questo modo la compilazione avrà priorità minore di tutti i processi SCHED_NORMAL. Durante la compilazione il sistema sarà abbastanza responsivo anche se non come nel caso precedente.

Ultima possibilità, nel caso abbiate un kernel vecchio o non abbiate installato gli schedtool è quella di lanciare la compilazione con nice 19 (la più bassa priorità di un processo SCHED_NORMAL):

$ nice -n 19 time fakeroot make-kpkg --append-to-version -desktop --revision 0.1 kernel_image

Ovviamente non è necessario compilare a bassa priorità, ma i casi precedenti sono stati riportati come esempio pratico di utilizzo degli schedtool e delle funzionalità delle patch -ck.

Una volta terminanta la compilazione sarà sufficiente acquisire i privilegi di root e installare il nuovo kernel con dpkg:

$ cd ../
# dpkg -i linux-image-4.0.0-ck1-bfs_1_amd64.deb

Utilizzo e Tuning

Lo scheduler BFS è stato progettato per esigenze desktop pertanto il numero di impostazioni su cui si può intervenire direttamente è limitato al minimo e nella maggior parte dei casi non è necessario fare cambiamenti per migliorare le prestazioni.
Quando lanciamo un processo in Linux questo sarà automaticamente SCHED_NORMAL. Per lanciare processi con altre classi di priorità bisogna usare gli schedtool; inoltre se vogliamo misurare il carico della cpu e i tempi di esecuzione possiamo usare il programma time (opzionale). I pacchetti si trovano nei repository Debian per cui basterà dare un

# apt-get install schedtool time

A questo punto, per lanciare un programma con priorità Idleprio si utilizza un comando del tipo

# schedtool -D -e apt-get dist-upgrade

in questo modo ad esempio eseguiremo un aggiornamento del sistema in background. Invece il comando che segue trasforma la shell corrente in SCHED_ISO

$ schedtool -I $$  

in questo modo tutti i programmi avviati con questa shell avranno priorità sched-iso e si alterneranno nell'utilizzo della cpu alla frequenza data dall' rr_interval.
L'intervallo di Round Robin è impostato di default a 6ms e può essere liberamente modificato scrivendo nel file /proc/sys/kernel/rr_interval; i valori accettati variano da 1 a 1000 millisecondi, ad esempio per impostare il valore a 100ms

# echo 100 > /proc/sys/kernel/rr_interval 

Con valori bassi migliora la latenza e cala il throughput, e vice versa. Alcune sperimentazioni hanno mostrato che aumentare l'rr_interval può migliorare il throughput fino a 300ms, mentre per valori superiori non ci sono ulteriori benefici. Inoltre bisogna tenere presente che l'accuratezza di questo intervallo è limitata dalla frequenza HZ del kernel, pertanto il valore di rotazione deve essere coerente col timer frequency impostato nella configurazione (in breve per valori dell'rr_interval bassi è necessaria una frequenza elevata).

Se si vuole eseguire una sola applicazione ISO per volta da una normale shell basterà dare un

$ schedtool -I -e amarok

questo farà partire amarok con priorità SCHED_ISO, in modo che, se necessario, possa interrompere qualsiasi task con priorità NORMAL o inferiore. Tuttavia siccome la priorità ISO è acccessibile ai normali utenti è stato stabilito un limite alle risorse utilizzabili da questi processi, in termini di percentuale di cpu disponibile sul pc; su un sistema multi-cpu il limite vale per il totale e non per ogni singola cpu. Il valore della cpu impegnata da un processo è calcolato come media mobile ogni 5 secondi e se un processo ISO utilizza più risorse di quelle prestabilite viene automaticamente rischedulato con priorità SCHED_NORMAL.
La precentuale massima di cpu utilizzabile è impostata nel file /proc/sys/kernel/iso_cpu e il suo valore di default è 70%. Questo valore può essere liberamente modificato, a seconda delle esigenze, in un range da 0 a 100; impostare un valore di 100 significa dare a tutti gli utenti accesso alla policy RR, mentre un valore di 0 impedisce l'esecuzione di un qualsiasi processo soft-realtime.
Per modificare il limite, ad esempio portarlo a 85, basta un

 # echo 85 > /proc/sys/kernel/iso_cpu 

Anche se per avviare un processo ISO non sono necessarie le credenziali di root, per garantire il mantenimento della priorità impostata dall'utente durante tutta la vita del processo, è necessario essere root per cambiare nuovamente la priorità al processo ISO mentre è già in esecuzione. Quindi, per esempio, se vogliamo reimpostare a SCHED_NORMAL amarok dovremo dare un

 # schedtool -N `pidof amarok` 

Infine è bene tenere presente che anche con le patch ck le priorità FIFO e RR sono accessibili solo a utenti coi privilegi di root e che lo scheduler BFS è progettato in modo da assegnare automaticmente la priorità ISO a qualsiasi applicazione che richiede priorità Sched_FIFO o Sched_RR senza avere privilegi necessari.

Il programma schedtool offre anche altre interessanti funzionalità; per maggiori dettagli man schedtool.

Links

Con Kolivas:

• Homepage delle patch Con Kolivas
• Quick walthrough on manually patching to -ck for beginners
• Con Kolivas Audio Hints

Kernel:

• Debian Kernel Howto
• Esempio configurazione kernel
• Low-latency 2.6 kernel per applicazioni audio realtime

---

Guida scritta da: Ombra (guida originariamente scritta da The Noise)	Debianized 20%
Estesa da:
Verificata da:
Verificare ed estendere la guida | Cos'è una guida Debianized