Lo Scheduling Real Time in Linux. Ivan Gualandri

Transcript

1 Lo Scheduling Real Time in Linux Ivan Gualandri 3 gennaio 2010

2 2

3 Indice Introduzione i 1 Scheduling e sistemi multi-core I processori multicore Cosa è lo scheduling Scheduling Real-Time Sistemi Real-Time Algoritmi Real-Time Rate Monothonic Scheduler EDF Scheduler Linux e lo scheduling Cenni Su Linux Lo scheduling in Linux Lo scheduling non real-time Lo scheduling RealTime Esempio di scheduling Real Time Perfomance Test Sistemi utilizzati per l esecuzione dei test Hardware Sistema Operativo Tool utilizzati per i test Sampling Kernel Debug tools Tymetest Tipologie di test effettuate Analisi Risultati e Grafici Task Singolo Due Task task concorrenti Conclusioni A Siti web di riferimento 43 3

4 4 INDICE B Glossario 45 C Script usati per i test 47 C.1 Test1.sh C.2 test2.sh

5 Elenco delle figure 2.1 Livelli di priorità di linux, e i relativi scheduler CPU Ideale del CFS RBTree dei processi Scenario iniziale di esempio Valori di pri active prima della push Valori di pri active dopo la push Le code dopo le operazioni di push e pull Grafico priorità/runtime processo nel caso di task singolo Grafico Runtime/Numero di Loop Grafico Tempi Latenza/Livello Priorità Grafico Durata Loop/Livello Priorità Grafico Durata Loop/Livello Priorità Grafico Latenza/Livello Priorità Grafico Latenza/Livello Priorità con scheduler FIFO Grafico Latenza/Livello Priorità con scheduler RR

6 6 ELENCO DELLE FIGURE

7 Elenco delle tabelle 1.1 Tabella con valori dell esempio per RMS Tabella con valori dell esempio per EDF Tabella con valori dell esempio per lo scheduler Linux Valori tipici di priorità per processi convenzionali Tabella con valori dell esempio per lo scheduler O(1) I

8 II ELENCO DELLE TABELLE YOU HAVE TO START OUT LEARNING TO BELIEVE THE LITTLE LIES. So we can believe the big ones? YES. JUSTICE. MERCY. DUTY. THAT SORT OF THING. They re not the same at all! YOU THINK SO? THEN TAKE THE UNIVERSE AND GRIND IT DOWN TO THE FINEST POWDER AND SIEVE IT THROUGH THE FINEST SIEVE AND THEN SHOW ME ONE ATOM OF JUSTICE, ONE MOLECULE OF MERCY. AND YET YOU ACT AS IF THERE IS SOME IDEAL ORDER IN THE WORLD, AS IF THERE IS SOME... SOME RIGHTNESS IN THE UNIVERSE BY WHICH IT MAY BE JUDGED.... Terry Pratchett - The Hogfather A tutti coloro che hanno creduto in me e mi hanno incitato a proseguire anche quando volevo fermarmi!!! (per non escludere nessuno :) )

9 Introduzione Obiettivi Gli obiettivi di questa tesi sono: Approfondire la conoscenza dei sistemi operativi real-time, con una particolare attenzione al kernel Linux Eseguire uno studio approfondito sul funzionamento dei vari scheduler di Linux che si sono susseguiti fino ad oggi. Analizzare il comportamento del kernel Linux in scenari in cui si utilizzano processi real-time Organizzazione del lavoro Il lavoro è diviso principalmente in 3 parti: 1. La prima parte introduce i concetti chiave, quali scheduling, real-time, processi, necessari per una comprensione chiara del testo. 2. La seconda parte invece spiega quali soluzioni sono state adottate nel sistema operativo Linux per le tematiche introdotte nella prima parte 3. La terza e ultima parte invece spiega come sono stati eseguiti i test, l hardware che stato adottato, e ne analizza i risultati, traendone le dovute conclusioni Prerequisiti Per una corretta lettura e comprensione del seguente lavoro sono richieste conoscenze almeno di massima dei seguenti argomenti: Sistemi Operativi Linux/Unix Shell Scripting Nozioni di C i

10 ii INTRODUZIONE Strumenti utilizzati per la stesura della tesi Nella stesura di questo lavoro sono stati utilizzati diversi strumenti, tutti quanti con una caratteristica comune: sono tutti Open Source (vedi glossario). Qui di seguito un breve elenco di cosa e stato utilizzato: L A TEX Con il quale è stata scritta la tesina. Si tratta di un linguaggio di mark-up per la preparazione di testi, basato sul programma di composizione tipografica TEX Gnuplot si tratta di un potente strumento per generare grafici Kile un ottimo ide per scrivere documenti latex e ovviamente l immancabile editor di testo vi per scrivere e modificare i vari sorgenti Per i dettagli sull hardware utilizzato, si veda il paragrafo 3.1. Come è strutturata la tesi Questo lavoro è diviso principalmente in tre parti. La prima parte, si occupa di creare un background teorico alla problematica, introducendo brevemente i concetti chiave dello scheduling, del real-time, presentando alcuni algoritmi di esempio. Mentre la seconda parte si occupa piu da vicino di quello che è lo scheduling di Linux, gli algoritmi che si sono succeduti nel tempo, e il suo approccio al Real-Time, spiegando anche qua quali algoritmi usa, come funziona la patch che e stata installata, i suoi pregi e difetti. Ogni algoritmo presentato è corredato di un esempio per comprenderne meglio il funzionamento. La terza e ultima parte invece si occupa di effettuare una serie di test sul kernel con la patch real-time. Verrà presentato l hardware su cui sono state eseguite le prove, le tipologie di test che sono state effettuate, i vari tools che sono stati utilizzati (cosa sono, come funzionano,...) e verranno presentati i risultati di questi test, cercando di evidenziare i punti di forza e debolezza dell approccio di linux al real-time. Dove è che le performance sono ottimali, e dove invece degradano, e per quale motivo lo fanno. Infine gli appendici conterranno i link ai vari siti dove è stato prelevato il materiale necessario allo svolgimento dei test, il glossario con i termini principali utilizzati nella stesura di questo lavoro

11 Capitolo 1 Scheduling e sistemi multi-core In questo capitolo ci si occuperà dello scheduling nei sistemi operativi. Verrà spiegato brevemente cosa si intende per scheduling, verranno illustrate le varie tipologie di scheduling, verrà introdotto lo scheduling real-time e verranno accennate alcune tecniche avanzate come il Group Scheduling. Inoltre si introdurrà anche il concetto di processore multicore. 1.1 I processori multicore I processori multicore sono una tipologia di processori nata nel 2001 (il primo modello fu il POWER4 della IBM) ma che ha avuto una visibilità maggiore nel 2005, quando furono introdotti sul mercato i modelli dual-core dei due maggiori produttori di CPU: Intel e AMD. Questi tipi di processori normalmente si trovano nel formato: dual, quad, six core (i six core sono stati annunciati sul mercato proprio in questi giorni). Questo tipo di processori uniscono 2 o più core, le rispettive cache e i controller in un singolo package (vedi [6]), ciò permette di aumentare la potenza di calcolo senza aumentare la frequenza di lavoro, a vantaggio del calore dissipato e del consumo elettrico. Il passaggio a questa tecnologia è stato deciso, quando i progettisti dei vari processori si resero conto, che per aumentare le prestazioni di un processore non era piu conveniente aumentare la frequenza di un core unico. Questa tecnica infatti pesava troppo in termini di consumo (i processori erano arrivati a consumare anche 100W) e di calore dissipato. Decisero quindi 1

12 2 CAPITOLO 1. SCHEDULING E SISTEMI MULTI-CORE di indirizzare lo sviluppo nella direzione del parallelismo sui chip multicore. Naturalmente ogni innovazione ha i suoi pro e contro. Un sicuro vantaggio della tecnologia multicore è di rendere possibile l esecuzione di due o più thread contemporaneamente (ovviamente dipende dal numero dei core). Mentre uno degli svantaggi è che per sfruttare al meglio le caratteristiche di questo tipo di processori bisogna scrivere del software orientato all utilizzo di più thread contemporaneamente, in modo da tenere impegnati i vari core al fine di non renderli inutilizzati. 1.2 Cosa è lo scheduling In un sistema multitasking, i processi alternativamente o utilizzano il processore o aspettano (semplicemente il proprio turno, o anche il completamento di qualche evento), questo permette all utente di far girare più programmi contemporaneamente, anche in presenza di un solo processore. Esistono principalmente tre tipi di scheduling 1. Long-Term Scheduling Si decide di aggiungere un processo all insieme dei processi che devono essere eseguiti 2. Mid-Term Scheduling Si decide di aggiungere un processo all insieme di quelli che sono parzialmente o completamente in memoria 3. Short-Term Scheduling Si decide quale processo disponibile sar eseguito dal processore. Alcune delle caratteristiche che deve uno scheduler sono: Essere trasparente al programmatore, ovvero chi si occupa di scrivere programmi per un sistema operativo, non deve curarsi del comportamento dello scheduler. Cambiare da un processo all altro in maniera veloce, in modo da aumentare la quantità di tempo dedicata all esecuzione del processo vero e proprio. Bilanciare il carico in maniera equa Assicurare che se vi sono task con una priorità maggiore, questi vengano eseguiti prima degli altri. I processi interattivi devono rispondere velocemente agli stimoli da parte dell utente.

13 1.3. SCHEDULING REAL-TIME 3 Ai job che lavorano in background deve comunque essere garantita la possibilità di portare a termine il loro lavoro in tempi ragionevoli. Nessun processo dovrebbe soffrire di starvation (vedere il glossario per il significato di starvation) 1.3 Scheduling Real-Time Sistemi Real-Time Quando si parla di Sistemi Operativi Real-Time (spesso si usa anche la sigla RTOS), si parla di sistemi nei quali i tempi di risposta di alcuni processi sono fondamentali, esempi di quando utilizzare un sistema operativo realtime sono: Applicazioni Militari Controllo di esperimenti di laboratorio Controllo di apparecchiature mediche Nei sistemi di questo tipo quindi ad essere importante non è il throughput, ma che venga garantita la deadline dei vari processi che la richiedono. Per meglio capire il concetto di Tempo Reale, definiamone anche i task. Innanzitutto è da notare che in questi sistemi non tutti i task possiedono questa caratteristica, e normalmente sono un numero limitato. I task realtime possono essere principalmente di due tipi: Hard Real-Time Questi sono dei task che devono essere eseguiti entro la loro scadenza altrimenti potrebbero causare malfunzionamenti. Soft Real-Time Ha una scadenza associata, che è desiderabile, ma non obbligatoria. Inoltre questo gli eventi che li generano possono essere o periodici o aperiodici il primo prevede che il processo real-time sia eseguito una volta ogni intervallo di tempo T, mentre il secondo invece prevede una scadenza in cui il task venga servito. Un sistema potrebbe dover rispondere a più task periodici di questo tipo, e in base a quanto tempo ogni task richieda, potrebbe non essere possibile gestirli tutti. Se per esempio abbiamo m task periodici con un periodo P i e richiede C i secondi di tempo CPU per gestire ogni evento, allora il carico di task periodici può essere dato solamente da: m i=1 C i P i 1

14 4 CAPITOLO 1. SCHEDULING E SISTEMI MULTI-CORE Uno degli obiettivi quindi dello scheduling real-time è fare in modo che l esecuzione dei processi rispetti il maggior numero di deadline (scadenze) possibile. La teoria dello scheduling real-time si può considerare divisa in 2 parti: Progettazione e implementazione dello scheduler L analisi dello scheduler nella quale si cerca di vedere se un certo scheduler soddisfi tutte le deadline di tutti i processi. Attenzione: Real-Time, non vuol dire migliori performance, ma bensì si determinismo e rispetto delle scadenze di un processo. 1.4 Algoritmi Real-Time Una delle cose interessanti da notare che la maggior parte dei sistemi operativi real-time odierni non è in grado di gestire le scadenze di un processo (come da definizione precedente), mentre tutti sono progettati per cercare di essere il più pronti possibile ai task in tempo reale, ovvero cercando di eseguirli con il minor ritardo possibile ed evitando se possibili altre interruzioni. Gli algoritmi per questi sistemi possono essere di due tipi principalmente: Dinamici, che effettuano le decisione in run-time Statici che invece prendono le loro decisioni quando il sistema viene lanciato. Vediamo brevemente alcuni di questi algoritmi Rate Monothonic Scheduler Il Rate Monothonic Scheduler (abbreviato RMS) è uno dei primi algoritmi studiati messo a punto da Liu e Layland nel In pratica questo algoritmo assegna le priorità ai task in base ai loro periodi. Dove per periodo T si intende la quantità di tempo compresa fra l arrivo di un istanza del task e la successiva. La frequenza di un task è l inverso del suo periodo. Normalmente la fine del periodo di un task coincide anche con la sua scadenza. Il tempo di esecuzione C è la quantità di tempo di elaborazione richiesta da ogni occorrenza del task, in un sistema mono processore il tempo di esecuzione non deve essere più grande del periodo, per cui si ha C < T

15 1.4. ALGORITMI REAL-TIME 5 Se tutti i processi vengono eseguiti sempre fino al termine, allora si può calcolare l utilizzazione del processore come: U = C T In questo tipo di algoritmo il task che ha la priorità piu alta è quello con il periodo pi breve. In un ambiente con priorità assegnate staticamente l RMS si può considerare un algoritmo ottimo. Liu & Layland hanno dimostrato che per un insieme di n task periodici esiste una schedulazione che soddisfi tutte le scadenze se è sotto un certo limite di tempo. Il test di schedulabilità per l RMS è una condizione necessaria ma non sufficiente con la quale viene garantito che tutti i processi vengano schedulati entro le loro scadenze, ed è data da: U = n i=1 C i T i n( n 2 1) dove C i e` il tempo di CPU richiesto, e T i è il tempo di rilascio. e n è il numero di processi che devono essere schedulati. Ora se il numero di processi tende a infinito, questa espressione tende a: lim n( n 2 1) = ln n Ovvero RMS può garantire tutte le scadenze con una utilizzazione del processore intrno al 69,3% e quindi il restante 30,7% della cpu può quindi essere utilizzato per la schedulazione di processi non real-time. L assegnazione delle priorità del RMS è anche ottima, ovvero se esiste un algoritmo di scheduling con priorità statiche può soddisfare tutte le deadlines, allora anche l RMS può farlo. Esempio Abbiamo il seguente scenario con 3 processi: Tabella 1.1: Tabella con valori dell esempio per RMS Processo Tempo di esecuzione Periodo P1 1 8 P2 2 5 P L utilizzazione del processore è data da: = 0,

16 6 CAPITOLO 1. SCHEDULING E SISTEMI MULTI-CORE Mentre la condizione sufficiente per cui possiamo dire che è un sistema schedulabile è: Ora dato che U = n( n 2 1) = 3( 3 2 1) = 0, , 725 < 0, possiamo concludere che il sistema è schedulabile EDF Scheduler Questo tipo di scheduling utilizza una coda di priorità e tiene in considerazione le scadenze di ogni task. Ogni volta che viene chiamata la funzione di schedulazione (il processo termina il suo lavoro, un nuovo processo viene lanciato) la coda viene analizzata alla ricerca del processo più vicino alla sua scadenza. Questo sar il prossimo a dover essere schedulato per l esecuzione. L EDF è un algoritmo ottimo su sistemi uniprocessore con prerilascio. Ovvero se una collezione di jobs indipendenti, ognuno dei quali con un suo istante di arrivo, una richiesta di esecuzione e una scadenza (deadline) questo verrà schedulato in modo tale che tutti i jobs completino il loro lavoro prima della scadenza. Nel caso ci sono processi periodici, che hanno anche questi delle scadenze (uguali al loro periodo) EDF ha una utilizzazione vicina al 100%. Il test di schedulabilità per EDF è quindi: U = m i=1 C i P i 1 Dove C i è il tempo di calcolo richiesto dal processo i-esimo e P i e il periodo del processo. Grazie a questo test EDF garantisce che tutte le scadenze sono rispettate e l utilizzazione totale della CPU non è al 100% Teorema 1. 1 Dato un insieme di tasks periodici or sporadici, con le relative scadenze uguali al periodo,l insieme dei task è schedulabile da EDF se e solo se: m C i U = 1 P i i=1 Corollario 1. EDF è un algoritmo ottimo, nel senso che se un insieme di tasks è schedulabile allora, è schedulabile anche da EDF. Dimostrazione. Infatti se U > 11 nessun algoritmo può schedulare con successo l insieme di task dato. Invece se U 1 allora tale insieme di tasks è schedulabile da EDF (e forse anche da altri algoritmi). 1 Per maggiori informazioni sulla dimostrazione consultare [20]

17 1.4. ALGORITMI REAL-TIME 7 Rispetto ad un algoritmo come l RMS l EDF garantisce il rispetto di tutte le scadenze anche con un carico molto alto. Ma questo algoritmo presenta anche alcune problematiche: Se il sistema è sovraccarico il numero di processi che non rispettano la scadenza non si puo prevedere. È un algoritmo molto difficile da implementare, e uno dei principali problemi è come rappresentare le scadenze e anche come arrotondarle. Per questo l EDF non si trova molto spesso come algoritmo per sistemi Real Time industriali. Anche se esistono alcuni sistemi operativi che lo implementano (per esempio Shark RTOS, ERIKA Enterprise, vedi appendici). Esempio Di schedulabilità Siano dati i seguenti 3 processi: Tabella 1.2: Tabella con valori dell esempio per EDF Processo Tempo di esecuzione Periodo P1 1 8 P2 2 5 P Eseguiamo il test di schedulabili`ta: U = m i=1 C i 1 = 1 P i = 0, 925 = 92, 5% 10 Ora dato che il limite per EDF di schedulabilita è il 100% della CPU, allora il sistema è schedulabile.

18 8 CAPITOLO 1. SCHEDULING E SISTEMI MULTI-CORE

19 Capitolo 2 Linux e lo scheduling In questo capitolo verrà fatta una breve introduzione del sistema operativo Linux, e se ne illustreranno le caratteristiche dello scheduler, le tecniche adottate, come quali algoritmi usa (per il real-time e non), come e`strutturato un processo 2.1 Cenni Su Linux Linux è un sistema operativo nato nato nel 1991, da un idea di Linus Torvalds, si ispirava inizialmente al sistema operativo Minix creato da Andrew. S. Tanenbaum professore all università di Amsterdam per scopi didattici. Iniziato quasi per gioco, oggi è un sistema molto usato in ambito server, e si sta diffondendo anche per usi domestici e di workstation. E scritto interamente in C e Assembler, ed è disponibile per diverse architetture hardware, i sorgenti sono rilasciati sotto licenza GPL che lo rendono liberamente modificabile da chiunque. In realta Linux è il nome del kernel, mentre quando si parla del sistema operativo, si usa il termine GNU/Linux, dove GNU è il nome del progetto creato da Richard Stallman che aveva l intento di creare un clone compatibile di Unix, composto interamente di software Libero, e grazie al kernel creato da Linus Torvalds, potè diventare un sistema operativo completo. In realtà il progetto GNU si sarebbe dovuto basare principalmente sul kernel Hurd 1, in sviluppo dal 1984, ma dato che cresceva a rilento, all inizio si decise di usare Linux (che stava crescendo molto velocemente nei primi anni 90) come kernel in attesa del completamento di hurd, che ad oggi, anche se ancora in sviluppo non e avvenuto. La tipologia adottata da questo kernel è monolitico/modulare. Un kernel si dice monolitoco quando tutti i servizi del sistema operativo, girano nel thread del kernel. Per modulare invece si intende la possibilita di poter 1 Per maggiori informazioni: 9

20 10 CAPITOLO 2. LINUX E LO SCHEDULING compilare alcune componenti del sistema operativo, come moduli del kernel, che si possono caricare solo quando ce ne è bisogno. Ad oggi il mondo di Linux è composto da svariate distribuzioni, spesso molto differenti tra loro, alcune sviluppate prettamente per l ambito desktop (come per esempio Ubuntu, Mandriva, OpenSuse), altre sviluppate pensando ad ambienti server (come Red Hat, Debian), altre magari specializzate per l utilizzo in ambito scientifico, cinematografico, e così via. Anche se tutte queste distribuzioni sono diverse tra loro, tutte condividono lo stesso kernel, quello di Linux. 2.2 Lo scheduling in Linux Prima di entrare nel dettaglio dello scheduler cerchiamo di spiegare come Linux gestisce i processi. In Linux un processo (o task) è una istanza di un programma che comprende il codice del programma, il contenuto delle variabili e lo stato del programma. A parte il codice, il resto varia durante l esecuzione del processo. Le informazioni sullo stato del processo si trovano nel Process descriptor La filosofia adottata dal kernel Linux è principalmente quella del time sharing, per la schedulazione dei processi, questo vuol dire che un task, viene eseguito per un determinato periodo di tempo, entro il quale se non e terminato viene messo in uno stato di riposo, e ne viene eseguito un altro. Inoltre ogni processo ha definita una priorità. Che va da 0 a 140, e in base al livello che ha, si useraún certo tipo di scheduler. Infatti esistono almeno 3 classi di scheduling, che sono: SCHED NORMAL indicato anche con SCHED OTHER si usa per le priorità che vanno da 139 a 101, queste indicano normalmente i processi non real-time, e quindi utilizzano l algoritmo di scheduling fornito di default dal kernel (per la serie prima della sarà O(1), mentre per le successive sarà CFS, spiegati in questo paragrafo) SCHED FIFO per i processi con priorità da 100 a 0, questo è uno degli algoritmi di scheduling disponibile per i processi di tipo Real-Time In questo caso non è previsto prerilascio e quindi un processo quando viene lanciato, resta in esecuzione fino al suo termine. E una classica coda Firs Int - First Out SCHED RR anche in questo caso si usa nei processi real-time, ma questa volta si tratta di un algoritmo con prerilascio, anche questo si può usare per processi con priorità da 100 a 0. In questo caso l algoritmo usato è di tipo Round Robin Se la priorità va da 0 a 99, in questo caso e possibile scegliere quale algoritmo far usare al processo. Infatti come si può notare, esistono due tipi di algoritmi per questi livelli di priorità.

21 2.2. LO SCHEDULING IN LINUX 11 Figura 2.1: Livelli di priorità di linux, e i relativi scheduler Lo scheduling non real-time Fra la versione 2.4 del kernel, e la versione 2.6 si sono susseguite 3 versioni differenti dello scheduler. In questo paragrafo le illustreremo brevemente, cercando di evidenziarne i lati positivi e negativi. Scheduling nella serie 2.4.x Il tempo viene suddiviso in periodi detti epoche, che si ripetono ciclicamente. Ogni volta che viene creato un processo, gli viene anche assegnato un quanto di tempo, che viene inserito nel campo counter del descrittore del processo. E il valore di counter viene inserito poi nel campo priority. Il quanto di tempo definisce un limite superiore al tempo di utilizzo di della CPU nell epoca in questione. Normalmente il quanto di tempo iniziale è di 20 clock ticks (o jiffies 2 ), il valore più alto ammissibile senza compromettere la reattività del sistema. Mediante la funzione nice(int n) si può variare il valore iniziale del quanto. Tramite la formula: priority = 20 - n Quando tutti i processi che si trovano nello stato TASK RUNNING hanno terminato il loro quanto, l epoca corrente termina e ne inizia un altra. Viene quindi ricalcolato di nuovo il quanto di tempo da assegnare ad ogni processo, in questo caso la formula utilizzata è: counter = counter 2 + priority (2.1) Cosi si premiano i processi I/Obound. Per capire meglio come lo scheduler premia i processi CPU Bound facciamo un piccolo esempio. Alla fine di un epoca si ha il seguente scenario: 2 Nelle vecchie versioni del kernel questo termine indicava il numero di tick del timer, invece nelle ultime versioni vale 10ms

22 12 CAPITOLO 2. LINUX E LO SCHEDULING Tabella 2.1: Tabella con valori dell esempio per lo scheduler Linux 2.4 Processo Counter Priority P P P Supponiamo che nessuno dei tre abbia il valore priority variato tramite nice (ovvero per tutti e 3 è 20). Ora all inizio della nuova epoca verranno assegnati nuovi quanti di tempo secondo la formula nell equazione 2.1, vediamo che valori assumeranno: P 1.counter = 10 2 P 2.counter = = = 30 P 3.counter = = 20 2 Come possiamo vedere il processo P2, che ha utilizzato meno CPU degli altri (si riconosce dal valore del campo counter), è stato premiato con un nuovo quanto di tempo maggiore rispetto agli altri processi. Mentre P3, che ha il suo quanto lo ha esaurito, è stato penalizzato e ha ricevuto una porzione minima del quanto di tempo Tutti i processi che sono schedulati con SCHED OTHER gli si assegna una prioritá statica pari a 0, mentre quella dinamica è assegnata come sopra. Mentre i processi real-time hanno una prioritá statica che assegnata fra i valori 1 e 99, e questa non cambia mai durante l esecuzione del processo. I passi che segue la funzione schedule() sono i seguenti: Completa eventuali system call in corso Se si tratta di un processo con SCHED RR ed ha esaurito il suo quanto viene rimesso in fondo alla coda, e gliene viene assegnato uno nuovo. Si analizza la coda dei processi pronti per selezionare quale è il prossimo ad essere eseguito mediante la funzione goodness. Questa se é in grado di scegliere il nuovo task ne prepara l esecuzione, altrimenti inizia una nuova epoca. La funzione goodness può tornare i seguenti valori: 1. c = 1000 Indica che questo processo non deve essere mai selezionato, e questo si verifica se nella runqueue corrente ci sta il solo processo init. 2. c = 0 Il processo ha terminato il suo quanto, a meno che il processo non sia il primo della sua lista e tutti gli altri process hanno esaurito il loro quanto, questo non verra selezionato.

23 2.2. LO SCHEDULING IN LINUX < c < 1000 Si tratta di un normale processo che non ha terminato il proprio quanto. Più è alto questo valore, e meglio è. 4. c >= 1000 Si tratta di un processo realtime. I problemi di questo approccio sono i seguenti: Le prestazioni del kernel degradano all aumentare del numero di processi In sistemi con carico elevato il valore definito per il quanto può essere troppo grande. Il supporto fornito per i processi RealTime non é ottimale. O(1) Scheduler É lo scheduler introdotto a partire dalla versione 2.6 che è rimasto fino alla Chiamato anche Constant Time Scheduling e cerca di occuparsi di alcuni problemi del vecchio scheduler. Il nome deriva dalla notazione asintotica usata spesso nel calcolo della complessita degli algoritmi. Questo tipo di scheduler utilizza due code di esecuzione per lo stato STATE RUNNING: active ed expired. La prima coda, contiene i task pronti per essere eseguiti che ancora non hanno consumato il loro quanto di tempo. La seconda invece contiene quelli che hanno ancora lo stato di TASK RUNNING ma che ha svuotato il suo quanto di tempo. Ogni CPU ha le sue code active ed expired 3, tutti i task in una CPU iniziano dalla coda active, e appena terminano il loro quanto, questi vengono messi nella coda expired. Se nella coda dei processi attivi non ci sono più task che si possono eseguire, le 2 code (active ed expired) vengono scambiate. Quando un processo finisce il suo quanto, e viene messo nella coda expired, gli viene riassegnato anche un nuovo timeslice. La chiave di questo algoritmo, da cui ne deriva anche il nome, è proprio nel ricalcolo delle timeslice. Infatti dal momento che il nuovo quanto di tempo viene calcolato quando un processo lascia la coda degli active per quella degli expired, non si verifica mai il caso in cui tutti i task necessitino contemporaneamente del ricalcolo delle timeslice, che avrebbe una complessita pari ad O(n), invece essendo fatto di volta in volta sui singoli processi, ed essendo scambiate le liste di volta in volta, si evitano tutte le operazioni che potrebbero richiedere una complessita di tipo O(n), e si ha quindi una complessita costante. Le priorità dei processi normali vanno, come gia detto in precedenza, da 140 (livello più basso) a 100 (quello piú alto). Queste priorità sono anche usate per ottenere il quanto di tempo per il singolo processo. 3 dette runqueue

24 14 CAPITOLO 2. LINUX E LO SCHEDULING Quando il processo si sposta nella coda degli expired, allora il nuovo quanto di tempo è calcolato come segue: { (140 static priority) 20 se static priority < 120 basetimequantum = (140 static priority) 5 se static priority 120 Cosi il valore del quanto di tempo base è dato dalla priorità statica, e più è alta la priorità, maggiore è il quanto di tempo che gli viene assegnato. Quando lo scheduler prende un nuovo task per metterlo in esecuzione usa invece la Priorità dinamica Il kernel utilizza la priorità statica solamente come punto di partenza, e la adatta in base al comportamento del task. Per farlo utilizza un bonus, che viene calcolato basandosi su quanto è il tempo medio di sleep per un dato processo e può variare da 0 a 10 compreso. La priorità dinamica è cosi calcolata: dynamic priority = max (100, min (staticpriority bonus + 5, 139)) Il valore bonus è calcolato secondo la seguente formula: CURRENT_BONUS(p)=(NS_TO_JIFFIES((p)->sleep_avg)*MAX_BONUS/MAX_SLEEP_AVG) Cioè converte il tempo medio del processo di sleep in Jiffies, lo moltiplica per il massimo bonus ottenibile e lo divide per il tempo medio di sleep massimo (questo valore indica il tempo massimo che può raggiungere il valore sleep avg ed equivale a 10 9 ns, ovvero 1 secondo). Infine il kernel divide i tasks in due tipi: Interattivi e batch, il primo ha bisogno di girare piuttosto velocemente, ma non necessita di molto tempo. I secondi invece sono normalmente processi che lavorano in background Per decidere se un task è interattivo o job si usa la seguente equazione: dynamic priority 3 static priority (2.2) Se un task soddisfa questa equazione allora si tratta di un processo interattivo. Tabella 2.2: Valori tipici di priorità per processi convenzionali Prio descr. Prio. Nice Base Time Quantum Interactivedelta Soglia sleeptime Max ms ms High ms ms Default ms ms Low ms ms Min ms ms Il valore di nice, è un altro indicatore di priorità, si tratta di un numero che va da -20 a 19. Il valore più grande corrisponde alla priorità più bassa,