Università degli Studi di Milano Bicocca Facoltà di Scienze Matematiche Fisiche e Naturali Corso di Laurea Specialistica in Informatica Real-time EDF scheduling per il kernel FreeBSD: analisi, implementazione e risultati sperimentali. Relatore: Dott. Sergio Ruocco Correlatore: Prof. Francesco Tisato Riassunto della tesi di Laurea di: Marco Trentini Matr. 062275 m.trentini@campus.unimib.it cel. 348-8423567 Anno Accademico 2010/2011 Seduta di Laurea del 24 Novembre 2011
I sistemi operativi Unix-like come Linux e FreeBSD nascono negli ultimi 20 anni per soddisfare requisiti in ambiti server e workstation. Recentemente trovato impiego anche in dispositivi embedded e mobili, in molti casi per applicazioni con requisiti real-time, come nel multimedia, per le applicazioni audio, video e di posizionamento, nel campo della robotica, automotive, e in generale, in applicazioni di controllo dove la tempistica di lettura e manipolazione di dati diventa indispensabile per ottenere risultati corretti. In Linux l attività di adattamento del kernel alle necessità delle applicazioni real-time è fervente da anni. Alcune società, come Montavista, Windriver e Timesys, hanno sviluppato e mantengono un propria versione del kernel Linux con supporto al real-time. La comunità opensource ha fornito diverse proposte per integrare il supporto al real-time nel kernel Linux, come OCERA, AQuoSA, Frescor, LITMUS-RT, RTLinux e RT-Preempt, per citare le maggiori. In FreeBSD non ci è nota alcuna iniziativa di adattamento del kernel alle necessità delle applicazioni real-time. Questa tesi presenta l implementazione per FreeBSD di un framework di scheduling real-time originariamente sviluppato per Linux, SCHED_DEADLINE, basato sull algoritmo di scheduling Earliest Deadline First (EDF), con l aggiunta di un meccanismo, noto come Constant Bandwidth Server (CBS), che limita il tempo di esecuzione dei task, garantendo un isolamento temporale tra essi. Scheduling di processi nei sistemi operativi La parte del kernel dedicata alle attività di scheduling di processi è chiamata scheduler. Lo scheduler organizza l esecuzione dei vari processi sulle risorse di calcolo disponibili, al fine di raggiungere certi obiettivi. L algoritmo di scheduling e le relative politiche dipendono quindi fortemente dal tipo e dagli obiettivi degli ambienti esecutivi. Inoltre dipendono dall architettura hardware dei sistemi, le architetture a multiprocessore ne sono un esempio. In genere possiamo suddividere gli ambienti esecutivi in batch, interattivi e in tempo reale. Nei sistemi batch (e.g. sistemi bancari e assicurativi) l interattività è messa in secondo piano, dando più importanza alle prestazioni di calcolo. In questo caso si usano algoritmi nonpreemptive oppure algoritmi preemptive ma con un lungo periodo di esecuzione per ogni processo (riducendo l overhead di switch di contesto). Nei sistemi interattivi (e.g. PC, server) l uso di un algoritmo preemptive è fondamentale per permettere un equa distribuzione del tempo di CPU a tutti gli utenti e dei tempi di risposta rapidi. Nei sistemi in tempo reale ci sono dei vincoli ben precisi sui tempi di esecuzione dei processi e spesso non è necessario un algoritmo preemptive in quanto ogni processo è a conoscenza di questi vincoli. Ad ogni modo, ad ogni interrupt di clock di sistema lo scheduler può verificare che siano rispettati i tempi di esecuzione dei processi e schedulare nuovi processi di conseguenza. Sistemi operativi Linux e FreeBSD Linux Linux è uno Unix-like molto popolare che viene utilizzato come sistema operativo su molte tipologie di elaboratori elettronici, dalle workstation ai server, ai multicomputer e di recente anche su diversi sistemi embedded come cellulari e altri dispositivi. Linux nasce dalle idee di uno studente fillandese, Linus Torvalds, che, prendendo spunto da Minix, sviluppa un nuovo sistema operativo. La prima release di Linux, la 0.01, viene rilasciata nel 1991. Il kernel Linux racchiude tutti quelle componenti fondamentali di un sistema operativo come i gestori degli interrupt, lo scheduler, i device driver, il gestore della memoria e diverse system call per fornire servizi di networking, di file system, di IPC e molti altri. 2
Il kernel Linux è quindi monolitico: tutte le sue componenti sono eseguite in un unico spazio di indirizzamento, in modalità kernel. La modalità di comunicazione tra le varie componenti è nella maggior parte dei casi quella classica a chiamata di funzione. La struttura del kernel Linux è modulare, nel senso che è possibile caricare in modo dinamico moduli del kernel specifici per certe funzionalità (e.g. device driver o supporto per un certo file system). FreeBSD FreeBSD è un sistema operativo Unix-like che trova il suo maggior impiego nell ambito dei server, per la fruizione dei servizi Internet. Inoltre viene utilizzato (in una percentuale molto inferiore rispetto a quella di Linux) nelle workstation, nei multicomputer (HPC) e anche nei sistemi embedded. Il progetto FreeBSD ha le sue origini agli inizi del 1993 con la patch Unoffical 386BSD PatchKit proposta da Nate Williams, Rod Grimes e Jordan Hubbard, cha andava a risolvere alcuni problemi della versione ufficiale di 386BSD di Bill jolitz. La prima versione di FreeBSD, la 1.0, fù rilasciata nel Dicembre del 1993. L architettura del kernel di FreeBSD è molto simile a quella del kernel Linux: si tratta di un kernel monolotico che racchiude le componenti fondamentali come i gestori degli interrupt, lo scheduler, i device driver, il gestore della memoria e diverse system call per fornire servizi di gestione di processi e IPC, di networking, di file system e molti altri. Il kernel, eseguito in modalità kernel ha un unico spazio di indirizzamento. La modalità di comunicazione tra le varie componenti è nella maggior parte dei casi quella classica a chiamata di funzione. Anche per FreeBSD è possibile caricare in modo dinamico moduli del kernel specifici per certe funzionalità (e.g. device driver o supporto per un certo file system). Scheduling in Linux Possiamo individuare l evoluzione dello scheduling nel kernel Linux in 5 filoni principali: kernel 1.1.x-1.2.x (1994-1995); kernel 2.0.x-2.2.x (1996-2004); kernel 2.4.x (2001-2008) kernel 2.6.0-2.6.22 (2003-2007); kernel 2.6.23-3.0 (2007 - Luglio 2011). Nel filone di kernel Linux 1.x lo scheduling si basa sulla tecnica a priorità con time sharing, il kernel non è preemptive e non c è il supporto a SMP. Nel filone di kernel Linux 2.0.x-2.2.x si introduce il meccanismo delle classi di priorità, secondo lo standard POSIX. Il calcolo delle priorità dinamiche per le classi di task utente tiene conto delle affinità dei task in CPU e favorisce i task I/O bound, in genere interattivi. In questo filone si introduce un supporto di base all SMP. Nel filone di kernel Linux 2.4.x si apportano alcune migliorie al supporto SMP e al calcolo delle priorità dei task utente. Nel filone di kernel Linux 2.6.0-2.6.22 si introduce il cosiddetto scheduler O(1) con una rivisitazione della gestione delle priorità e del riconoscimento dei task interattivi. Inoltre troviamo un kernel preemptive e l uso della tecnica a priorità ereditata per il problema di priorità inversa. Ogni risorsa di calcolo manitene una propria lista di task che può eseguire, ed è stato introdotto un bilanciamento di carico periodico basato sul domain scheduling. Nel filone di kernel 2.6.23-3.0 si introduce una nuova tecnica di scheduling modulare e la politica CFS che cerca di distribuire equamente il tempo di esecuzione delle risorse di calcolo ai task utente. Inoltre si introduce la tecnica di group scheduling, che permette di distribuire il tempo di calcolo a gruppi di task utente. 3
Scheduling in FreeBSD L architettura del kernel di FreeBSD ha subito un notevole cambiamento a partire dalla release 5.0 con il progetto FreeBSD SMPng Project, che introduce il supporto all SMP. Obiettivi della nuova architettura sono un alta scalabilità (come numero di unità di calcolo), basse latenze per gli interrupt e un kernel il più possibile prelazionabile. Possiamo individuare l evoluzione dello scheduling dei processi in FreeBSD in due scheduler principali: 4BSD (default in FreeBSD 1.X-6.X); ULE (default a partire da FreeBSD 7.X). 4BSD Lo scheduler di FreeBSD 4BSD si basa sullo scheduler del sistema operativo 4.3BSD, il sistema operativo da cui FreeBSD deriva. 4BSD è uno scheduler a classi di priorità: in una decisione di scheduling si manda in esecuzione il task con priorità maggiore. I task delle classi kernel hanno priorità statiche e non hanno time slice: possono essere prelazionati solo da processi di maggiore priorità o quando passano in stato di attesa (sleep o attesa di I/O). I task delle classi utente hanno delle time slice e le relative priorità sono calcolate in modo dinamico, con lo scopo di favorire i task interattivi, I/O bound, a discapito dei task CPU bound. Il calcolo delle priorità dinamiche avviene in modo periodico, con una complessità temporale di O(n), con n numero totale di task sul sistema, risultando poco efficiente con alti carichi di lavoro. In 4BSD si utilizza la tecnica a priorità ereditata per il problema di priorità inversa. Altre caratteristiche di 4BSD sono un supporto a POSIX real-time e la possibilità di prelazionare task in spazio kernel, aumentando la reattività del sistema sui cambi di priorità dei task. Inoltre lo scheduler 4BSD ha un supporto di base alle architetture a multiprocessore (CPU multicore e core multi-tasking SMT e HTT), secondo il modello SMP. Ogni risorsa di calcolo (e.g. CPU o core) ha associato una lista di task che può eseguire. Il bilanciamento di carico avviene in modo statico, in fase di decisione della CPU sulla quale assegnare un nuovo task. Nella decisione si tiene conto dell eventuale affinità dei task, cercando di assegnare task sulle stesse CPU sulle quali sono stati eseguiti in precedenza. L obiettivo di 4BSD è dare massima priorità esecutiva ai task in spazio kernel, minimizzare i tempi di risposta per i task utente interattivi (I/O bound) e avere un supporto di base per le architetture a multiprocessore, secondo il modello SMP. ULE Lo scheduler ULE è stato sviluppato nel contesto del progetto FreeBSD SMPng Project. ULE come 4BSD è uno scheduler a classi di priorità: in una decisione di scheduling si manda in esecuzione il task con priorità maggiore. I task delle classi kernel hanno priorità statiche e non hanno time slice: possono essere prelazionati solo da processi di maggiore priorità o quando passano in stato di attesa (sleep o attesa di I/O). I task delle classi utente hanno delle time slice e le relative priorità sono calcolate in modo dinamico, con lo scopo di favorire i task interattivi, I/O bound, a discapito dei task CPU bound. Rispetto a 4BSD, dove il calcolo delle priorità dinamiche avveniva in modo periodico, con una complessità temporale di O(n), in ULE la priorità dinamica viene aggiornata solo per il task in esecuzione, con una complessità temporale di O(1), risultando efficiente anche con alti carichi di lavoro. Come per 4BSD, ULE utilizza la tecnica a priorità ereditata per il problema di priorità inversa. Altre caratteristiche di ULE sono un supporto a POSIX real-time e la possibilità di prelazionare task in spazio kernel, aumentando la reattività del sistema sui cambi di priorità dei task. In ULE è stato migliorato il supporto SMP. E stato introdotto un riconoscimento della 4
topologia delle CPU: nelle decisioni di bilanciamento di carico, oltre all affinità dei task in CPU, si tiene conto della distanza di cache. Inoltre, rispetto a 4BSD, dove il bilanciamento di carico avveniva solo in modo statico, in ULE abbiamo anche un bilanciamento di carico periodico. L obiettivo di ULE è dare massima priorità esecutiva ai task in spazio kernel, minimizzare i tempi di risposta per i task utente interattivi (I/O bound), ridurre la complessità temporale nelle decisioni di scheduling e migliorare il supporto alle architetture a multiprocessore, secondo il modello SMP. Real-time EDF per FreeBSD: implementazione e risultati Per quanto riguarda il supporto al real-time in FreeBSD, inteso come un kernel il più possibile prelazionabile, e dove lo scheduler implementa, attraverso le sue politiche, almeno un algoritmo di scheduling real-time, non sono ad oggi conosciute proposte. Al contrario, in Linux, il tema del real-time viene affrontato da anni, correlato da diverse proposte. Possiamo individuare il mancato supporto al real-time in FreeBSD in tre aspetti principali: la mancanza di una politica di scheduling basata su un algoritmo di scheduling real-time, che tenga conto dei vincoli temporali di esecuzione dei task; un kernel maggiormente prelazionabile, per evitare lunghe latenze prima che un task real-time possa essere mandato in esecuzione; la mancanza di un supporto a timer ad alta risoluzione, indipendenti dal clock di sistema, per una gestione della banda di utilizzo dei task realt-time. In Linux, per ognuno di questi aspetti, sono state proposte delle soluzioni: SCHED_DEADLINE che introduce una nuova politica di scheduling, basata sull algoritmo di scheduling realtime EDF, RT-Preempt che aumenta notevolmente la possibilità di prelazionare tutte le attività che convivono nel kernel, e gli htimer per supportare timer ad alta risoluzione. Le politiche di scheduling che ritroviamo nel kernel ufficiale di FreeBSD, implementate nelle classi di scheduling ithd, real-time, timeshare e idle, funzionano egregiamente nel loro contesto applicativo (e.g. server/desktop). Ad ogni modo queste politiche non possono fornire garanzie su vincoli temporali di esecuzione richieste dalle applicazione real-time. Infatti, le decisioni di scheduling di tutte le classi non si basano su vincoli temporali di esecuzione dei task ma bensì sulla relativa priorità e, per alcune classi, sul relativo quanto esecutivo a disposizione. Con queste politiche non è possibile garantire un budget temporale esecutivo (vincolo - budget esecutivo) di un task rispettando una deadline temporale (vincolo - deadline relativa), ad esempio specificare che un task possa essere eseguito per 20 millisecondi con una deadline relativa di 100 (calcolata nel momento in cui il task va in stato di pronto). Inoltre, il tempo trascorso tra due esecuzioni consecutive di un task (vincolo - periodo relativo) non è deterministico e non può essere fissato a priori. Il rispetto di questi vincoli è fondamentale nelle applicazioni real-time per ottenere risultati corretti. Senza uno scheduler che tenga conto dei vincoli temporali dei task, di fatto, non è possibile fare uno studio di fattibilità del sistema, e non ci sono garanzie che siano rispettati i vincoli temporali di esecuzione dei task. DEADLINE-BSD è una nuova politica di scheduling real-time per lo scheduler ULE di FreeBSD, mutuata da Linux, che implementa l algoritmo di scheduling EDF, con l aggiunta di un meccanismo per limitare il tempo di esecuzione dei task, garantendo un isolamento temporale tra essi. A causa delle sostanziali differenze tra il kernel Linux e FreeBSD, come ad esempio la 5
gestione dei timer, dei lock, il framework di scheduling, le strutture dati, per citarne alcune, questo lavoro non può essere considerato come un semplice porting della classe di scheduling real-time fatta per Linux, ma bensì una re-implementazione della stessa. In questa implementazione, un task real-time viene rappresentato dalle seguenti informazioni: dl_runtime: massimo tempo di esecuzione (relativo) di ogni istanza del task, alias budget; dl_deadline: deadline (relativa) entro la quale deve essere consumato il budget a disposisizone dell istanza corrente del task; dl_period: periodo di tempo (relativo) all interno del quale può essere attivata un istanza del task; nella nostra implementazione coincide con la deadline relativa. dl_bw: banda di utilizzo del task, ottenuta dal rapporto tra il dl_runtime e dl_period, ed utilizzata per validare il workload real-time nel test di ammissione. exec_start: tempo di sistema di inizio esecuzione dell istanza del task; runtime: tempo di esecuzione rimanente per l istanza corrente del task (inizialmente pari a dl_runtime); deadline: deadline assoluta (in tempo di sistema) dell istanza corrente del task; La classe di scheduling deadline è stata progettata in ULE in modo tale da lasciare inalterate le caratteristiche di funzionamento delle altre classi, ithd, real-time, timeshare e idle. Per quanto riguarda la priorità esecutiva della classe deadline, è stato deciso di dare una priorità maggiore rispetto alle classi utente real-time, timeshare e idle, ma minore rispetto alla classe ithd. Un task con deadline ottiene una fase di computazione in CPU (chiamata istanza), che può essere attivata in modo periodico, sporadico, o aperiodico, a seconda dell implementazione del task stesso. La durata (massima) di computazione dell istanza di un task è contenuta nel campo dl_runtime della struttura informativa del task, mentre il lasso di tempo entro il quale questa computazione deve avvenire, chiamata deadline relativa, è contenuto nel campo dl_deadline. La deadline assoluta, campo deadline, viene calcolata di volta in volta ed è pari al tempo assoluto del sistema nel quale viene attivata l istanza del task, sommato alla sua deadline relativa. Il periodo di tempo entro il quale può essere attivata una nuova istanza del task è contenuto nel campo dl_period. Per attivazione di un istanza del task si intende il primo passaggio in stato di pronto del task all interno del periodo. La banda di utilizzo dei task, campo dl_bw, è determinata dal rapporto tra il budget assegnato e il relativo periodo, ossia dl_runtime/dl_period. In questa versione di DEADLINE-BSD il periodo dl_period coincide con la deadline relativa dl_deadline. Questo significa che il budget di ogni istanza del task (dl_runtime) può essere consumato all interno di tutto il periodo (dl_period). In una decisione di scheduling l algoritmo EDF seleziona il task da mandare in esecuzione sulla base dei valori delle deadline assolute (campo deadline) dei task: viene mandato in esecuzione il task con il minor valore di deadline, ossia la deadline più prossima alla scadenza. La gestione della capacità esecutiva dei task deadline è regolata dai seguenti parametri di sistema (sysctl): kern.sched.dl_period_us (default a 1000000 usec o 1 sec); 6
kern.sched.dl_runtime_us (default a 500000 usec o 0.5 sec); Questi parametri restituiscono (se letti) o settano (se scritti) il budget totale di esecuzione per i task deadline all interno del relativo periodo, per ogni CPU del sistema. I valori di default permettono di riservare un tempo di CPU pari a 50 millisecondi ogni secondo per eseguire task appartenente alle altri classi utente. Questa gestione della capacità di calcolo per i task deadline, insieme all assunzione che l informazione di periodo e di deadline dei task coincidono, ci permettono di definire il seguente controllo di ammissione : somma delle bande di utilizzo dei task deadline < M (dl_runtime_us/dl_period_us), con M numero di CPU del sistema. Questo controllo garantisce una capacità di calcolo sufficiente per eseguire il workload real-time. Ogni task deadline sottomesso nel sistema, viene validato dal controllo di ammissione: se il controllo fallisce, il task non può essere inserito. In FreeBSD la gestione dei timer in kernel (callout) è legata alla frequenza del clock principale di sistema, definita dalla variabile di configurazione del kernel HZ. Questo significa che non è possibile armare timer con una risoluzione inferiore al periodo di clock di sistema. Con valore di HZ pari a 1000 riusciamo ad armare timer con un timeout di, al massimo, un millisecondo, e quindi riusciamo a gestire task con vincoli temporali non inferiori al millisecondo. La granularità dei timer influisce sulla risoluzione e precisione che possiamo avere nei vincoli temporali dei task deadline. Infatti i timer sono utilizzati per controllare la banda di utilizzo dei task e per attivare nuove istanze. Per i thread deadline è stato previsto un bilanciamento di carico statico per configurazioni SMP. Quando bisogna decidere (nella funzione su quale CPU allocare un nuovo thread deadline, si determina la CPU con minor carico di thread deadline e sufficiente banda. Questa ricerca viene effettuata solo per nuovi thread deadline, ossia thread a cui non è stata ancora riservata banda di utilizzo su qualche CPU, altrimenti la CPU selezionata è quella sulla quale è stata allocata la banda di utilizzo. Per la gestione dei thread deadline in userspace sono state aggiunte quattro nuove syscall: sched_getparam_ex(), sched_getscheduler_ex(), sched_setparam_ex(), sched_setscheduler_ex(). Per verificare l implementazione di DEADLINE-BSD sono state condotte alcune prove sperimentali. L ambiente di test è composto da una macchina reale, con la seguenti caratteristiche hardware: AMD Athlon(tm) 64bit X2 Dual Core Processor 5200+ (2700.27-MHz K8-class CPU). La versione di FreeBSD installata è la 8.2.0. Il kernel è stato ricompilato con la patch deadline-bsd. Una prima suite di test verifica il rispetto del budget esecutivo e della deadline/periodo di un task deadline (in while(1)), eseguito più volte con diversi vincoli temporali. Una seconda suite di test mette a confronto le tre classi scheduling utente: deadline, real-time e timesharing. Un task while(1) (timeout di 3 secondi) viene mandato in esecuzione in un workload con un alto carico di lavoro. Si vuole verificare il comportamento esecutivo del task a seconda della classe di scheduling assegnata. Un workload con un alto carico di lavoro può essere rappresentato da un task in while(1) con la priorità maggiore per le classi utente, quindi classe di scheduling real-time con valore di priorità 128 (ricordiamo che in ULE tutte le classi di scheduling utente 7
funzionano in timesharing e quindi il while(1) non può monopolizzare l esecuzione in CPU). I risultati ottenuti mostrano come un sistema FreeBSD dotato di questa classe di scheduling possa gestire workload real-time periodici e aperiodici rispettando i vincoli di tempo di esecuzione, deadline e periodo, anche in presenza di un elevato carico di sistema. Questo lavoro apre la possibilità di impiegare FreeBSD anche in ambiti applicativi con requisiti real-time, dove Linux è il sistema operativo Unix-like dominante. Inoltre bisogna considerare che la licenza BSD-style di FreeBSD presenta meno restrizioni di quella GPL del kernel Linux e questo rende FreeBSD più appetibile per le aziende nella scelta del sistema operativo da adottare. 8