Porting su architettura ARM ed analisi comparativa delle patch real-time PREEMPT_RT e Xenomai per il kernel Linux

Transcript

1 Università Politecnica delle Marche Facoltà di Ingegneria Dipartimento di Ingegneria dell Informazione Corso di Laurea in Ingegneria Informatica e dell Automazione Porting su architettura ARM ed analisi comparativa delle patch real-time PREEMPT_RT e Xenomai per il kernel Linux Tesi di: Alessandro Galdelli Relatore: Prof. Aldo Franco Dragoni Correlatore: Dott. Andrea Claudi Anno Accademico 2011/2012

2 Alla mia famiglia

3 Ringraziamenti La seguente tesi rappresenta la parte finale di questo primo percorso di studi, costituito da momenti di difficoltà e sconforto ma anche di gioia e felicità. Desidero ringraziare tutte le persone che hanno contribuito al raggiungimento di tale traguardo e che mi hanno permesso di realizzare questa tesi. Ringrazio il Prof. Dragoni per la sua totale disponibilità, per aver reso possibile questo lavoro di tesi e per i suoi consigli che mi hanno aiutato a superare gli inconvenienti incontrati durante la sua realizzazione. Desidero ringraziare di cuore Andrea Claudi che quotidianamente mi ha seguito e sostenuto durante tutta la durata del tirocinio, aiutandomi a risolvere qualsiasi tipologia di difficoltà e senza il quale non avrei potuto terminare il lavoro di tesi. Un sentito ringraziamento va ai miei genitori Enzo e Mariangela, a mia sorella Lucia e mia nonna Maria per avermi sostenuto in tutti i miei anni di studio, per avermi incoraggiato, per aver gioito insieme nei momenti felici e per avermi permesso di continuare gli studi in tutta serenità. Grazie di cuore. Un ringraziamento speciale va anche ai miei nonni, Giovanni e Gemma, i quali sarebbero stati molto soddisfatti del traguardo raggiunto. Un grandissimo ringraziamento va alla mia fidanzata Mariasole, per essermi stata sempre vicina e per aver sopportato tutti i miei sbalzi d'umore soprattutto in questa fase conclusiva di studi. Desidero ringraziare tutti i miei amici conosciuti durante gli anni universitari, in particolar modo Feida, Matteo e Andrea con i quali ho preparato la maggior parte degli esami sostenuti. Infine ringrazio tutti i parenti e gli amici di vecchia data per essermi stati sempre vicino e per avermi aiutato a crescere come persona. Grazie a tutti! Ancona, Luglio 2012 Alessandro Galdelli i

4 Sommario Il lavoro svolto in questa tesi ha come obiettivo quello di portare una suite di test per sistemi operativi in tempo reale su architettura ARM. Il lavoro complessivo è diviso in tre parti principali. La prima parte è basata sullo studio e documentazione del sistema operativo Linux e della scheda ARM utilizzata, approfondendo in particolar modo lo studio dei sistemi in tempo reale, basati sempre sul kernel Linux; l'implementazione di un sistema real-time è stata ottenuta tramite l'applicazione di due diverse patch, quella PREEMPT_RT e quella di Xenomai, che riescono a fornire al sistema operativo originale funzionalità real-time. Nella seconda parte del lavoro svolto, tutto lo sforzo è stato incentrato nella configurazione e nella cross compilazione del kernel Linux nelle diverse modalità real-time per la scheda ARM e nel porting della suite di test. Infine, l'ultima parte del lavoro è stata quella di verificare la funzionalità e le prestazioni delle diverse configurazioni utilizzando la suite di test, raggruppando i risultati ottenuti in apposite tabelle. ii

5 Indice Introduzione...1 Stato dell'arte Caratteristiche generali di un RTOS Task periodici/aperiodici e hard/soft real-time Sistemi Hard e Soft real time Schedulazione dei sistemi real time Classificazione degli algoritmi di scheduling Caratteristiche di un sistema real time Standard per sistemi real-time GNU/Linux GPL Scenario di utilizzo dei RTOS Soluzioni real time per il kernel Linux PREEMPT_RT Schedulazione CFS Preemption Patch Low Latency Patch Xenomai Architettura del progetto Adeos pipeline Adeos e Xenomai I domini di Xenomai Intercettare le chiamate di sistema Propagazione degli interrupt Board Marvell SheevaPlug Architettura ARM Il microcontrollore come sistema embedded CPU Marvell 88F Contatori e timers iii

6 2.5.5 La cross-compilazione Il lavoro svolto Lavoro di porting Installazione della toolchain CodeSourcery PREEMPT_RT su piattaforma ARM MV88F Xenomai su piattaforma ARM MV88F Valutazione delle soluzioni rispetto agli aspetti implementativi Test Cyclictest PREEMPT_RT Latency Test Xenomai Risultati dei test Conclusioni e sviluppi futuri Bibliografia iv

7 Elenco delle figure Figura 1 - Parametri temporali caratteristici di un processo... 6 Figura 2 - Coda di processi pronti in attesa di esecuzione Figura 3 - Macchina a stati che modella l'evoluzione di un task Figura 4 - Dispositivi di comunicazione con il sistema domotico Figura 5 - Applicazioni pratiche nel "Sistema-casa" Figura 6 - Struttura di sistema operativo basato sul primo approccio (sinistra) e sul secondo approccio (destra) Figura 7 - Esempio di RB-Albero Figura 8 - Schema dell'architettura di Xenomai Figura 9 - Schema dell'astrazione introdotta dalla pipeline Adeos Figura 10 - Gestione di Adeos su domini multipli con n CPU Figura 11 - Migrazione tra domini Figura 12 - Interrupt shield Figura 13 - Schema a blocchi della board Marvell 88F Figura 14 - Tipico scenario applicativo della board Marvell 88F Figura 15 - Schermata del menuconfig di PREEMPT_RT Figura 16 - Schermata del menuconfig di Xenomai Figura 17 - Messaggi in fase di avvio di Linux relativi al nanokernel Xenomai Figura 18 - Grafico ad area dei risultati del test Cyclictest Figura 19 - Esecuzione del programma in background Figura 20 - Grafico ad area della somma delle latenze del secondo test con il kernel "vanilla" e PREEMPT_RT Figura 21 - Grafico ad area della somma delle latenze del terzo test con il kernel "vanilla" e PREEMPT_RT Figura 22 - Istogramma valori latenze massime dei diversi test con Xenomai Figura 23 - Istogramma valori latenze medie dei diversi test con Xenomai Figura 24 - Istogramma valori latenze minime dei diversi test con Xenomai v

8 Elenco delle tabelle Tabella 1- Confronto degli aspetti implementativi di Xenomai e PREEMPT_RT 64 Tabella 2 - Risultati test Cyclictest per PREEMPT_RT e "vanilla" Tabella 3 - Risultati test Cyclictest con programma in background per PREEMPT_RT e "vanilla" Tabella 4 - Risultati test Cyclictest con ping per PREEMPT_RT e "vanilla" Tabella 5 - Risultati test Cyclictest con funzione di analisi abilitata per PREEMPT_RT e "vanilla" Tabella 6 - Risultati Latency test del nanokernel Xenomai Tabella 7 - Risultati Latency test con programma in background del nanokernel Xenomai Tabella 8 - Risultati test con ping del nanokernel Xenomai vi

9 Capitolo 1 Introduzione Il lavoro svolto in questa tesi ha come obiettivo quello di portare una suite di test per sistemi operativi in tempo reale su architettura ARM. L'architettura ARM (precedentemente Advanced RISC Machine, prima ancora Acorn RISC Machine) definisce una famiglia di microprocessori RISC a 32-bit sviluppata da ARM Holdings e utilizzata in una moltitudine di sistemi embedded. Grazie alle sue caratteristiche di basso consumo (rapportato alle prestazioni) l'architettura ARM domina il settore dei dispositivi mobili dove il risparmio energetico delle batterie è fondamentale. Attualmente la famiglia ARM copre il 75% del mercato mondiale dei processori a 32 bit per applicazioni embedded, ed è una delle più diffuse architetture a 32 bit del mondo. I processori ARM vengono utilizzati in palmari, cellulari, tablet, lettori multimediali, videogiochi portatili e periferiche per computer (come router, hard disk di rete ecc). Oggigiorno i sistemi embedded sono molto diffusi nel mondo dell'informatica e dell'elettronica, e ciò è dovuto al prezzo ridotto e alle prestazioni che possono offrire questi tipi di sistemi. Per sistemi embedded intendiamo tutti quei sistemi elettronici di elaborazione a microprocessore progettati appositamente per una determinata applicazione, spesso con una piattaforma hardware ad hoc, integrati nel sistema che controllano ed in grado di gestirne tutte o parte delle funzionalità richieste. Lo scopo di questa tesi è quello di testare l'efficienza dell'ultima versione del sistema operativo Linux in versione real-time su una scheda ARM di ultima generazione e di valutarne le prestazioni. La suite di test presa in considerazione ha lo scopo di fornire una serie di test affidabili per la valutazione delle funzionalità e delle performance di sistemi real-time come RTAI, Xenomai, RT PREEMPT e naturalmente del kernel Linux stesso. Un sistema operativo real-time è usato quando sono richiesti rigidi vincoli di tempo sulle operazioni del processore o sul flusso di dati, quindi spesso è impiegato come dispositivo di controllo per un'applicazione dedicata. Un sistema operativo real-time ha come 1

10 CAPITOLO 1 - INTRODUZIONE 2 obiettivo quello di minimizzare la latenza dei suoi processi, definita generalmente come l'intervallo di tempo tra l'istante di occorrenza di un evento e l'inizio dell'azione corrispondente a quell'evento. Un sistema operativo real-time non deve necessariamente essere veloce: non è importante l'intervallo di tempo in cui il sistema operativo deve reagire; l'importante è che risponda entro un tempo massimo pre-determinato o scadenza (detta anche deadline). In altre parole il sistema deve essere prevedibile. I sistemi operativi in tempo reale rivestono un ruolo fondamentale nella nostra società coprendo diversi settori applicativi, quali il controllo di impianti industriali, il controllo di impianti sanitari, i sistemi di regolazione di volo, il controllo del traffico aereo, navale e ferroviario, il trasferimento dei dati nelle telecomunicazioni, i sistemi di difesa militari, le missioni spaziali, i sistemi multimediali, l'automazione industriale e la robotica. Oggigiorno, la soluzione di utilizzare il sistema operativo Linux per applicazioni in tempo reale è molto diffusa, grazie soprattutto alla robustezza e performance del sistema stesso. Ciò nonostante, Linux è stato progettato per essere un sistema general-purpose e dunque si possono verificare problemi quando vengono eseguite applicazioni real-time; Linux infatti, può presentare latenze impredicibili e una risoluzione dei tempi non ottimale per il contesto di sistemi operativi in tempo reale. A tal proposito sono sorte alcune modifiche, sottoforma di patch, per prevenire questi problemi e per aggiungere le caratteristiche real-time al kernel "vanilla" di Linux. In questo lavoro di tesi è stata svolta una indagine sulle varie alternative real-time disponibili sul kernel Linux, cioè quella relative alla patch RT PREEMPT e alla patch Xenomai per la scheda ARM, sia in termini di costo temporale nell'implementazione del porting sulla board che per quanto riguarda le prestazioni real-time; in particolare, per lo svolgimento di questa tesi la scheda utilizzata è la board Marvell "SheevaPlug" con processore MV88F6281 (con set di istruzioni ARMv5te). I risultati ottenuti sono conformi a ciò che ci aspettavamo, cioè che nella modalità real-time il kernel è molto più prestazionale del kernel "vanilla", sia in termini di latenza che di velocità computazionale. La tesi è stata organizzata illustrando nel Capitolo 1 i concetti base che caratterizzano i sistemi embedded, facendo una panoramica sull'architettura ARM e sui sistemi real-time. Nel capitolo 2 vengono descritte le caratteristiche generali

11 CAPITOLO 1 - INTRODUZIONE 3 di un sistema real-time, la tecnica di scheduling utilizzata nella patch RT PREEMPT e in quella di Xenomai, la classificazione degli algoritmi di scheduling e gli standard attualmente in uso per i sistemi a tempo reale. In particolar modo vengono descritte nel dettaglio tutte le caratteristiche delle due soluzioni real-time adottate, della licenza GNU utilizzata da Linux e dei componenti principali della scheda ARM SheevaPlug. Nel capitolo 3 vengono illustrate le procedure di installazione di Xenomai e di RT PREEMPT sulla board SheevaPlug, il lavoro di porting della suite di test e i risultati ottenuti dai test nelle diverse configurazioni del kernel Linux. Infine nel capitolo 4 vengono espresse le conclusioni su questo lavoro di tesi e gli sviluppi futuri sia sul campo scientifico che in quello industriale.

12 Capitolo 2 Stato dell'arte 2.1 Caratteristiche generali di un RTOS Un sistema operativo a tempo reale, chiamato brevemente anche RTOS, è un sistema operativo specializzato per il supporto ad applicazioni software real-time. I sistemi che controllano esperimenti scientifici, come i sistemi per la rappresentazione di immagini in medicina, i sistemi di controllo industriale e alcuni sistemi di visualizzazione sono tutti sistemi real-time. Si possono considerare tali anche alcuni sistemi per autovetture a iniezione, controllori di apparecchiature domestiche e sistemi d'arma. Nonostante la vastità degli scenari coinvolti, la maggior parte dei sistemi real-time viene ancora progettata con tecniche empiriche, senza l'ausilio di una metodologia scientifica consolidata. La conseguenza di ciò è una scarsa affidabilità del software che, in applicazioni critiche, può causare gravi danni a cose o persone. Questi sistemi vengono utilizzati tipicamente in ambito industriale (controllo di processo, pilotaggio di robot, trasferimento dati nelle telecomunicazioni) o comunque dove sia necessario ottenere una risposta dal sistema entro un tempo prefissato. Un sistema operativo real-time non deve essere necessariamente veloce: non è importante l'intervallo di tempo in cui il sistema operativo/applicativo deve reagire; l'importante è che risponda entro un tempo massimo pre-determinato. In altre parole il sistema deve essere prevedibile. In pratica un sistema real-time deve garantire che una elaborazione (o task) termini entro un dato vincolo temporale o scadenza (detta in gergo deadline). Per garantire questo è richiesto che la schedulazione delle operazioni sia fattibile. Il concetto di fattibilità di 4

13 CAPITOLO 2 - STATO DELL'ARTE 5 schedulazione è alla base della teoria dei sistemi real-time ed è quello che ci permette di dire se un insieme di task sia eseguibile o meno in funzione dei vincoli temporali dati Task periodici/aperiodici e hard/soft real-time I task di un sistema real-time possono essere: periodici : quando un task consiste in una sequenza di attività avviate con cadenza regolare aperiodici : quando un task consiste in una sequenza di attività avviate ad intervalli irregolari I task periodici sono propri di un sistema di controllo a tempo discreto. Quando si ha a che fare con task di tipo periodico si parla anche di periodo di esecuzione con il quale si identifica il lasso di tempo che intercorre tra due attivazioni del task. Solitamente si fa coincidere la deadline con la fine del periodo poiché questo è il limite massimo di esecuzione di un task. Un ulteriore distinzione dei task real-time è la seguente: soft real-time: un task che non rispetta la sua scadenza (in gergo si dice sfondare la deadline) provoca un danno non irreparabile al sistema. Il superamento della deadline produce un degrado delle prestazioni proporzionale al tempo di superamento della deadline. hard real-time: un task che nel caso superi temporalmente la sua deadline provoca un danno irreparabile al sistema. Sostanzialmente questa distinzione si traduce nella diversa quantificazione dei costi di una possibile inesattezza temporale del sistema. Un esempio di task soft real-time può essere un riproduttore DVD, in cui il mancato rispetto dei vincoli si traduce in un degrado della qualità del filmato, ma non pregiudica il proseguimento della riproduzione; mentre un task hard real-time può essere il

14 CAPITOLO 2 - STATO DELL'ARTE 6 controllore della temperatura del nocciolo di una centrale nucleare, dove il mancato rispetto dei vincoli temporali può provocare un evidente disastro. I sistemi operativi general purpose non supportano la funzionalità hard real-time ma possono supportare quelle di tipo soft (ad esempio Linux è un sistema soft real-time). In generale un sistema operativo di tipo real-time sarà caratterizzato sia da task di tipo hard che di tipo soft. I parametri che caratterizzano il comportamento temporale di un processo sono i seguenti: arrival time (a): istante di tempo in cui il task diventa pronto per l esecuzione; computation time (C): tempo necessario al processore per eseguire completamente un task senza interruzioni; deadline (d): istante di tempo entro cui il task deve essere completato; start time (s): istante di tempo in cui il task va in esecuzione per la prima volta; finishing time (f): istante di tempo in cui il task termina la sua esecuzione. Il significato e le relazioni tra i parametri sopra definiti sono chiariti nella Figura 1. Figura 1 - Parametri temporali caratteristici di un processo Esistono altri tre parametri che caratterizzano temporalmente un task e sono utilizzati per analizzare le prestazioni di un algoritmo di schedulazione: lateness (L): rappresenta il ritardo di completamento del task rispetto alla deadline ed è così definita: L = f - d

15 CAPITOLO 2 - STATO DELL'ARTE 7 si osservi che per un task che completa la propria esecuzione prima della deadline la lateness è negativa. tardiness (E): rappresenta il tempo in cui un processo è rimasto attivo oltre la propria deadline: E = max{0,l} è detto anche exceeding time. laxity (LX): rappresenta il ritardo di attivazione massimo che un task attivo può subire nella ready queue senza per questo violare la deadline: LX = d - a - C Sistemi Hard e Soft real time Esistono due tipi di sistemi real-time. Un sistema hard real-time garantisce che i compiti critici siano completi in un dato intervallo di tempo; tale requisito può essere garantito se tutti i tempi di attesa nel sistema sono ben delimitati, dal prelievo dei dati memorizzati al tempo necessario al sistema operativo per completare le operazioni richieste su tali dati. I vincoli temporali impongono l'uso di dispositivi hardware che sono generalmente presenti nei sistemi hard real-time, mentre è limitata, o addirittura mancante, una memoria secondaria di qualsiasi tipo, poiché i dati sono memorizzati in una memoria a breve termine o in una di sola lettura (ROM). Quest'ultima, diversamente dalla maggior parte degli altri tipi di memorie, è posta in dispositivi di memorizzazione non volatili che conservano il proprio contenuto anche in caso di interruzione dell'energia elettrica. I sistemi real-time mancano di gran parte delle caratteristiche comuni agli altri sistemi operativi avanzati, dal momento che questi ultimi tendono a separare l'utente dall'hardware e rendono incerto il tempo di esecuzione di una operazione. Sistemi

16 CAPITOLO 2 - STATO DELL'ARTE 8 real-time con caratteristiche meno restrittive sono i sistemi soft real-time dove i task real-time critici hanno priorità sugli altri task e la mantengono sino al completamento dell'esecuzione. Come nei sistemi hard real-time le attese del kernel devono essere limitate: un task real-time non può restare indefinitamente in attesa che il kernel lo metta in esecuzione. Le caratteristiche soft real-time possono essere inserite in sistemi di altro tipo, che hanno comunque un'utilità più limitata dei sistemi hard real-time; infatti la mancanza di supporto a elaborazioni con vincoli di tempo ne rende pericoloso l'utilizzo nel controllo industriale e nella robotica. Ci sono comunque diverse aree tra cui multimedialità, realtà virtuale, progetti di ricerca scientifica avanzati, come l'esplorazione sottomarina e planetaria, in cui tali sistemi sono molto utili. Essi necessitano di caratteristiche avanzate dei sistemi operativi che non possono essere supportate dai sistemi hard real-time. L'utilizzo sempre più diffuso delle funzionalità soft real-time ne ha indotto l'introduzione nei più attuali sistemi operativi, comprese le principali versioni di UNIX. Per chiarire meglio il concetto si può pensare ad un sistema real-time come ad un sistema che, dato un insieme di task, ognuno con i propri vincoli temporali (deadline del task -esimo), è in grado di minimizzare la funzione di costo definita come: dove è la funzione di costo del task -esimo definita come: se il task -esimo è di tipo hard real-time, o come: se il task -esimo è di tipo soft real-time, dove si è indicato con una funzione monotona crescente all'aumentare del tempo che scorre. I task di tipo hard real-time dovranno quindi essere schedulati in modo da terminare ad un istante minore della deadline in modo da far valere la funzione di costo 0 e non ; mentre i task soft real-time dovranno anche loro far valere 0

17 CAPITOLO 2 - STATO DELL'ARTE 9 la funzione di costo relativa ma, in questo caso, uno sfondamento della deadline non manderà il costo globale del sistema all'infinito (equivalente al disastro). In entrambi i casi, il comportamento real time è ottenuto dividendo un programma in processi il cui comportamento è prevedibile e noto in anticipo. Questi processi hanno normalmente una vita breve e possono essere eseguiti nella loro completezza in un tempo inferiore al secondo. Nel momento in cui viene rilevato un evento esterno, lo scheduler dei processi ha il compito di determinare un'opportuna sequenza di esecuzione dei processi tale da garantire il rispetto di tutte le scadenze. Come descritto nella sezione precedente, gli eventi a cui un sistema real time deve poter reagire possono essere classificati in task periodici e aperiodici. Nel caso di eventi periodici, se esistono m task e se il task i-esimo arriva con periodo Pi e richiede Ci secondi di tempo di CPU per essere gestito, il carico può essere gestito solo se: M Ci Pi i=1 1 Un sistema real time che rispetta questo vincolo è detto schedulabile. Ad esempio, consideriamo un sistema soft real time con tre eventi periodici di periodo 100, 200 e 500 millisecondi, rispettivamente. Se questi eventi richiedono rispettivamente 50, 30 e 100ms di tempo di CPU per la loro esecuzione, il sistema è schedulabile in quanto: 50/100+30/ /500 = 0, 5 + 0, , 2 1. Se un quarto evento, con periodo di 1 secondo, si aggiunge al sistema, l'insieme dei processi rimarrà schedulabile fino a quando a questo evento non richiederà più di 150ms di tempo di CPU per occorrenza. Notare che nel calcolo precedente si suppone implicitamente che l'overhead per il cambio di contesto sia così piccolo da poter essere trascurato. I sistemi operativi general purpose non supportano la funzionalità hard real-time ma possono supportare quelle di tipo soft (ad esempio Linux è un sistema soft real-time).

18 CAPITOLO 2 - STATO DELL'ARTE Schedulazione dei sistemi real time Quando un singolo calcolatore deve portare a termine l'esecuzione di più processi, si pone il problema di individuare una strategia di gestione che sequenzializzi l'uso della macchina fisica in base ad un criterio prefissato: Figura 2 - Coda di processi pronti in attesa di esecuzione L'algoritmo di scheduling è l'insieme di regole che determinano la scelta del processo da mandare in esecuzione tra i processi pronti. In genere, l'ordinamento della coda pronti viene fatto in modo che il processo da eseguire sia il primo della coda. Alcuni sistemi prevedono che il processo in esecuzione possa essere interrotto in qualsiasi istante e riportato in coda pronti, al fine di consentire ad un processo attivo più importante di completare la sua esecuzione. L'operazione di liberare il processore e riportare il processo in esecuzione in coda pronti viene detta preemption. L'assegnazione effettiva del processore al processo pronto schedulato viene detta dispatching ed è effettuata dal sistema operativo dopo l'operazione di scheduling. Ciò che differenzia un sistema non real-time da un RTOS è principalmente lo schedulatore. Nei sistemi operativi real-time la preemption offre i seguenti vantaggi: Quando i task hanno diversi livelli di importanza, la preemption permette di anticipare l'esecuzione dei task più importanti. Le routine che devono gestire le eccezioni del sistema operativo devono poter interrompere il task in esecuzione per svolgere le azioni appropriate nel più breve tempo possibile. Una schedulazione preemptive consente una maggiore efficienza nell'uso

19 CAPITOLO 2 - STATO DELL'ARTE 11 delle risorse di calcolo, permettendo un maggiore carico computazionale in presenza di vincoli temporali. Lo schedulatore è un algoritmo che controlla l'accesso alla CPU da parte dei vari processi del computer. La schedulazione dei processi è fondamentale per garantire l'efficienza computazionale del computer, garantendo un utilizzo ottimizzato della CPU tra processi che evolvono parallelamente, tenendo conto degli interrupt prodotti dai controller delle varie unità I/O, dalle memorie, dagli hard-disk Concetti generali I possibili stati di un task sono: New. Il processo viene creato. Running. Le istruzioni vengono eseguite. Waiting. Il processo attende che si verifichi qualche evento (come il completamento di un I/O o la ricezione di un segnale). Ready. Il processo attende di essere assegnato a un processore. Terminated. Il processo ha terminato l'esecuzione. Figura 3 - Macchina a stati che modella l'evoluzione di un task Le decisioni riguardanti lo scheduling di CPU possono essere prese nelle seguenti circostanze: 1. Quando un processo passa da stato running a stato waiting 2. Quando un processo passa da stato running a stato ready 3. Quando un processo passa da stato waiting a stato ready 4. Quando un processo termina

20 CAPITOLO 2 - STATO DELL'ARTE Quando un nuovo task è ammesso alla coda ready Diversi algoritmi di scheduling della CPU hanno proprietà differenti e possono favorire una particolare classe. Per il confronto tra gli algoritmi di scheduling della CPU sono stati suggeriti molti criteri. Le caratteristiche utilizzate per il confronto possono incidere in modo rilevante sulla scelta dell'algoritmo migliore. Di seguito sono riportati alcuni tra i criteri utilizzati: Utilizzo di CPU. La CPU deve essere attiva il più possibile, ovvero devono essere ridotti al minimo i possibili tempi morti. Throughput: il numero di processi completati in una determinata quantità di tempo. Tempo di completamento: il tempo che intercorre tra la sottomissione di un processo ed il completamento della sua esecuzione. Tempo d'attesa: il tempo in cui un processo pronto per l'esecuzione rimane in attesa della CPU. Tempo di risposta: il tempo che trascorre tra la sottomissione del processo e l'ottenimento della prima risposta. Tra i criteri sopra elencati, l'unico utile alla valutazione degli algoritmi di scheduling real-time è il tempo di risposta, che deve essere inferiore alla deadline per ogni task Classificazione degli algoritmi di scheduling A seconda delle ipotesi che si assumono sui processi e sul tipo di architettura hardware di supporto all'applicazione, gli algoritmi di scheduling per sistemi real-time possono essere suddivisi in diverse classi, tra loro ortogonali: Preemptive. Sono quegli algoritmi in cui il processo in esecuzione può essere sospeso in qualsiasi istante, allo scopo di assegnare il processore ad un altro processo attivo. Non-preemptive. Sono quegli algoritmi in cui un processo, una volta ricevuto il processore, continua l'esecuzione fino al suo completamento. Le

21 CAPITOLO 2 - STATO DELL'ARTE 13 decisioni di scheduling vengono effettuate solo dopo il completamento di un task. Statici. Sono quegli algoritmi in cui la regola di decisione è basata su parametri fissi, che sono assegnati ai processi una volta per tutte, prima della loro attivazione. Dinamici. Sono quegli algoritmi in cui la regola di decisione è basata su parametri dinamici, che possono variare durante l'esecuzione dei processi. Off-line. Rappresentano quegli algoritmi in cui tutte le decisioni scheduling sono prese prima dell'attivazione dei processi, sulla base di informazioni note a priori. La schedulazione viene memorizzata in una tabella, che a run time viene eseguita da un dispatcher. On-line. Rappresentano quegli algoritmi in cui le decisioni di scheduling vengono effettuate a run time sull'insieme corrente dei processi attivi. L'ordinamento dei task viene quindi ricalcolato ad ogni nuova attivazione. Ottimi. Sono algoritmi in grado di produrre una soluzione che minimizza una data funzione di costo definita sull'insieme di task. Euristici. Sono algoritmi che operano in base ad una funzione di costo definita globalmente su tutto l'insieme di task, ma che, al fine di ridurre la complessità di calcolo, producono soluzioni non ottimali. Negli algoritmi off-line i vincoli di precedenza e di mutua esclusione possono essere integrati implicitamente nello scheduling (implicit synchronization), nel senso che ciascun processo può essere attivato solo quando le risorse da esso richieste sono disponibili e quando tutti i suoi predecessori sono stati eseguiti. Viceversa, negli algoritmi on-line, i vincoli di precedenza e di mutua esclusione devono essere forzati da costrutti di sincronizzazione espliciti. Se i vincoli di precedenza e di mutua esclusione vengono integrati nello scheduling, il problema di trovare una schedulazione off-line fattibile equivale ad un problema di ricerca su un grafo di complessità non polinomiale (NP). Tuttavia, in alcuni casi non è richiesta una soluzione ottima e ci si accontenta di algoritmi

22 CAPITOLO 2 - STATO DELL'ARTE 14 euristici. Tra gli algoritmi di scheduling più utilizzati per i sistemi real-time troviamo: EDF (Earliest Deadline First), EDD (Earliest Due Date) e RM (Rate Monotonic). L'EDF ha le seguenti caratteristiche: Tutti i task arrivano simultaneamente. La priorità è dinamica. Non necessita di preemption. Minimizza la Lateness. L'EDD ha le seguenti caratteristiche: I task possono arrivare in un qualsiasi istante. Priorità dinamica in base alla deadlines imminente. Utilizza la capacità dei task di fare preemption su altri. Minimizza la Lateness. RM è utilizzabile solo per task periodici, ha le seguenti caratteristiche: Ai task viene assegnata una priorità statica proporzionale alla frequenza di arrivo. Un gruppo di task è schedulabile se conosciuta la funzione di utilizzazione U è U<U_lub. La funzione U esprime il tasso di utilizzazione del processore, la funzione risulta limitata superiormente ed è SupU=1, indicando con U_lub fattore di utilizzazione minimo. Diremo che una funzione è certamente schedulabile con Rate Monotonic se U<U_lub, risulta invece non schedulabile se U>1. Se U_lub<U<1 non abbiamo certezza sulla schedulabilità. L'algoritmo EDF in alcune circostanze risulta migliore di RM perché garantisce la schedulabilità semplicemente per U<1. Per approfondire la conoscenza su questi algoritmi di scheduling e per conoscerne altri meno comuni, si consiglia di vedere [1].