Real-time EDF scheduling per il kernel FreeBSD: analisi, implementazione e risultati sperimentali

Real-time EDF scheduling per il kernel FreeBSD: analisi, implementazione e risultati sperimentali Marco Trentini m.trentini@campus.unimib.it Relatore: Dott. Sergio Ruocco Correlatore: Prof. Francesco Tisato Facoltà di Scienze Matematiche Fisiche e Naturali Corso di Laurea Specialistica in Informatica Sessione del 24 Novembre, 2011

Roadmap della presentazione 1 evoluzione dei sistemi operativi Unix-like 2 FreeBSD, Linux, e sue varianti real-time 3 lo scheduler real-time SCHED DEADLINE per Linux 4 porting di SCHED DEADLINE per FreeBSD 5 risultati sperimentali 6 conclusioni e sviluppi futuri

Evoluzione dei sistemi operativi Unix-like

FreeBSD Origini, impieghi e caratteristiche principali FreeBSD nasce nel 1993 come derivazione di 386BSD la versione non commerciale di Unix sviluppata da UC-Berkeley impiegato per server, workstation e recentemente in alcuni sistemi embedded (TV Panasonic) lo scheduler (ULE) non ha supporto per il real-time...... e nella comunità non sono note iniziative in tal senso! ha una licenza (BSD) tecnicamente e commercialmente molto meno restrittiva di quella Linux (GPL)

Real-time Linux Stato dell arte Linux viene oggi impiegato in svariati ambiti: multimedia, sistemi embedded e mobili, cellulari, smartphone (Android), consumer electronics (TV, navigatori), robotica... dal 1999 si tiene il Real Time Linux Workshop, seminario internazionale dedicato al supporto ed impiego di Linux in ambiti real-time. varianti con supporto commerciale: Montavista, Windriver e Timesys; varianti con supporto communità: OCERA, AQuoSA, Frescor, LITMUS-RT, RTLinux e Preempt-RT; Variante scelta per questa tesi: SCHED DEADLINE SCHED DEADLINE = EDF + isolamento temporale (Constant Bandwidth Server) implementazione per Linux nel contesto del progetto europeo ACTOR guidato da Ericsson Research con la partecipazione, tra gli altri, di Scuola S. Anna (PI) incapsulata in un componente (modulo Linux) - lo scheduler è modulare dalla versione 2.6.23 licenza Gnu Public License (GPL) V2 free software

Modello dei task real-time in SCHED DEADLINE

FreeBSD (sched)ule: strutture dati

(sched)ule + SCHED DEADLINE = FreeBSD real-time!

Risultati sperimentali Ambiente di test: AMD Athlon(tm) 64bit X2 Dual Core Processor 5200+ (2700.27-MHz K8-class CPU); FreeBSD 8.2.0 con patch deadline-bsd (HZ=10000) Tool: modifica di sched getparam ex e relativi parametri per portare in user space informazioni di scheduling dei thread real-time; KTR, sched switch e GtkWave per visualizzare gli eventi di scheduling in formato grafico. Misurazioni: 1 rispetto dei vincoli temporali di esecuzione; 2 confronto con le altre classi di scheduling.

Risultati sperimentali - (1) SCHED DEADLINE Legenda: sh tid 100063: task di classe real-time Posix (massima priorità, simula alto carico); sh tid 100092/93/94: task di classe deadline con runtime 200/300/300(us) e deadline 1/2/3(ms); colore linea: rosso per task ready; verde/azzurro per task running; giallo per task not ready;

Risultati sperimentali - (1) SCHED DEADLINE Osservazioni: rispetto priorità esecutiva; rispetto di max runtime (isolamento temporale); rispetto delle deadline (EDF); preemption tra task real-time (EDF);

Risultati sperimentali - (2) classe standard di ULE Legenda: sh tid 100085: task di classe real-time Posix (massima priorità e in while(1), simula alto carico); sh tid 100069-72: task di classe real-time Posix (massima priorità e in while(1)); colore linea: rosso per task ready; verde/azzurro per task running; giallo per task not ready;

Risultati sperimentali - (2) classe standard di ULE Osservazioni: max runtime dipende dalla time slice (default a 100ms per tutti i task); periodo di esecuzione dipende dal numero di task in stato di pronto (in Round Robin);

Conclusioni e direzioni future Risultati ottenuti: il porting di SCHED DEADLINE in FreeBSD è stato effettuato con successo; FreeBSD può essere impiegato in ambiti applicativi con requisiti real-time. Lavori futuri: vincolo deadline diverso dal periodo; integrare altri algoritmi di scheduling real-time (come moduli);

(Extra) Cosa è stato fatto - Teoria e pratica Parte teorica: studio sulla teoria dello scheduling di processi nei sistemi operativi; scheduling in Linux e FreeBSD con ricerca di proposte real-time. Parte pratica: implementazione/trapianto di SCHED DEADLINE nello scheduler di FreeBSD con risultati sperimentali.

(Extra) FreeBSD - Scheduling di processi Due scheduler: 4BSD, ereditato da 4.3BSD (obsoleto); il più recente ULE (da schedule), scheduler di default per la maggior parte delle architetture supportate; Obiettivi massima priorità esecutiva ai task kernel; minimizzare i tempi di risposta per i task utente interattivi; supporto per architetture multicore (SMP).

(Extra) FreeBSD - Scheduling di processi Caratteristiche di ULE: classi di priorità: in una decisione di scheduling si manda in esecuzione il task con priorità maggiore; classi kernel con priorità statiche e senza time slice; classi utente con time slice e calcolo delle priorità dinamiche con lo scopo di favorire i task interattivi; complessità temporale di O(1) (in 4BSD era O(n)); tecnica a priorità ereditata per il problema di priorità inversa; supporto alle classi di scheduling real-time POSIX sched fifo e sched rr; bilanciamento di carico statico e periodico basato su affinity e distanza di cache, per architetture multicore (SMP).

(Extra) FreeBSD - Scheduling real-time (?!) FreeBSD manca di: scheduling che tenga conto di vincoli temporali; kernel preemptive a grana più fine; timer ad alta risoluzione [1ms... 10us]; Cosa risolve l implementazione di SCHED DEADLINE in FreeBSD?

(Extra) Deadline-BSD - classe di scheduling Nuova classe di scheduling deadline. Precedenza di esecuzione: minore rispetto alle classi kernel; maggiore rispetto a tutte le classi utente; Motivazioni: evitare di ritardare l esecuzione dei gestori degli interrupt; rispetto dei vincoli temporali richide la precedenza su altri task utente; gestione della capacità di calcolo per allocare banda di utilizzo per altre classi.

(Extra) Deadline-BSD - Gestione dei task Strutture dati: modifica struttura informativa dei thread; albero binario red-black (per-cpu); banda di utilizzo disponibile ed effettiva (per-cpu); Albero red-black ogni nodo rappresenta/punta ad un task; ordinato sulla base delle deadline assolute dei task; il nodo più a sinistra è quello con il minor valore; complessità temporale di gestione dell albero di O(log n).

(Extra) Deadline-BSD - Isolamento temporale EDF non garantisce il rispetto del budget di esecuzione dei task. Controllo del budget: agganciato alla gestione dei tick del clock di sistema; quando un task esaurisce il suo budget viene stoppato e ri-attivato (tramite un timer) sulla base del periodo. Cosa otteniamo? l istanza del task può restare in esecuzione per al massimo il suo budget; un task non può monopolizzare la CPU, influenzando l esecuzione di altri task.

(Extra) Deadline-BSD - Gestione banda di utilizzo Gestione della banda di utilizzo (per-cpu) dei task di classe deadline regolata da due parametri di sistema: Sysctl: kern.sched.dl period us (default a 1s); kern.sched.dl runtime us (default a 600ms);

(Extra) Deadline-BSD - Test di ammissione Test di ammissione: n dl bw <= C (dl runtime us/dl period us) i=0 con C numero di CPU del sistema e n numero di task di classe deadline in stato di pronto. Cosa garantisce? sufficiente banda di CPU per rispettare i vincoli temporali di esecuzione dei task. Cosa non garantisce? l effettivo rispetto dei vincoli temporali.

(Extra) - Deadline-BSD - Granularità Uso dei timer in Deadline-BSD: per attivare nuove istanze di task; per controllare il budget di esecuzione dei task; I timer in FreeBSD sono legati alla frequenza del clock principale di sistema (parametro di configurazione del kernel, HZ). Cosa implica? non è possibile armare timer con una risoluzione inferiore al periodo di clock di sistema; diminuisce la precisione nel rispetto dei vincoli; frequenze troppo alte del clock di sistema comportano instabilità (es. a 1us).

(Extra) - Deadline-BSD - SMP Gestione del bilanciamento di carico per i task di classe deadline separata da quella standard di ULE. Scelta della CPU per i nuovi task: banda di utilizzo sufficiente; minir carico di task di classe deadline; la banda rimane allocata fino al uscita (exit/kill) del task.

(Extra) Deadline-BSD - Integrazione in ULE Innesto di Deadline-BSD in ULE: nuove strutture dati e relative inizializzazioni; scelta del task da mandare in esecuzione; switch di contesto; fork di thread; tick di stathz; tick di hz; passaggio del thread in stato di pronto; yielding; uscita di un thread.

(Extra) Deadline-BSD - Chiamate di sistema syscall: int sched_getparam_ex(pid_t, struct sched_param_ex *); int sched_getscheduler_ex(pid_t); int sched_setparam_ex(pid_t, const struct sched_param_ex *); int sched_setscheduler_ex(pid_t, int, const struct sched_param_ex *); struct sched_param_ex { int sched_priority; struct timespec sched_runtime; struct timespec sched_deadline; struct timespec sched_period; unsigned int sched_flags; struct timespec curr_runtime; struct timespec used_runtime; struct timespec curr_deadline; };

(Extra) Deadline-BSD - Risultati sperimentali - (1) Statistiche di scheduling: while(1) per 3 secondi con diversi vincoli temporali 200us/1ms 300us/2ms 300us/3ms (runtime/deadline) tot rtime usec 600289 450430 300306 (runtime totale) rtime over usec 289 430 306 (runtime totale in eccesso) last rorun usec 1 73 9 (ultimo runtime in eccesso) rorun max usec 99 99 99 (massimo runtime in eccesso) cnt dmiss 0 0 0 (nbr deadline mancate) cnt rorun 3000 1502 1001 (nbr runtime in eccesso) cnt timerfire 3000 1502 1001 (nbr attivazione timer) cnt resched 3000 1502 1001 (nbr rischedulazione) cnt updatecurr 6166 4600 3576 (nbr update runtime)

(Extra) Deadline-BSD - Risultati sperimentali - (1) Osservazioni: rispetto della banda di utilizzo grazie all isolamento temporale, (valori di tot rtime usec e figura); rispetto della deadline (cnt dmiss a 0); preemption tra task di classe deadline con EDF (preemption del task 94); rorun max use non va mai oltre la risoluzione del tick di clock di sistema (in questo caso pari a 100us);