The performance of microkernel based system
- 1. Università degli Studi di Salerno Laurea Magistrale in Informatica Corso di Sistemi Operativi Avanzati The Performance of 𝜇-Kernel-Based Systems Prof. Giuseppe Cattaneo Sergio Guastaferro
- 2. Autori della ricerca ▪ Hermann Härtig ▪ Michael Hohmuth ▪ Jochen Liedtke (IBM) ▪ Sebastian Schönberg ▪ Jean Wolter
- 3. ▪ Interessi di Ricerca : ▪ Sistemi Real-Time ▪ OS basati su microkernel ▪ Security in OS ▪ Dal ‘82 attivo nel campo della ricerca ▪ Dal 1994 professore di Sistemi Operativi presso la Technische Universität Dresden Hermann Härtig 3
- 4. ▪ Nel 1996 si laurea in Computer Science presso la Technische Universität Dresden ▪ Inizia quindi un dottorato di ricerca nello stesso campo presso la stessa università ▪ Continua gli studi come ricercatore fino al 2006 dove.. ▪ Lascia gli studi per la posizione di Operating Systems Architect, fino al 2012 ▪ Diventa CEO di un’azienda spinoff della Technische Universität Dresden che commercializza L4 ▪ Ha scritto pubblicazioni circa L4Linux e cura la documentazione di esso Michael Hohmuth 4
- 5. ▪ A metà degli anni ‘70 studia per la laurea in matematica presso l’Università di Bielefeld; Il suo progetto di tesi era quello di costruire un compilatore per il linguaggio di programmazione ELAN ▪ Dopo la sua laurea nel 1977, rimane a Bielefeld e lavora in un ambiente ELAN per il microprocessore Zilog Z80 sul progetto EMUEL ▪ Si parla di memoria virtuale e meccanismi di protezione ▪ Nel 1984, è entrato a far parte del GMD, Centro nazionale tedesco di ricerca per l'informatica ▪ Nel 1987, quando i microprocessori iniziano a supportare la memoria virtuale, iniziò a progettare un nuovo OS che chiamò L3 ("Il terzo sistema di Liedtke", dopo Eumel e l’interprete Algol 60 che aveva scritto al liceo). ▪ Nel 1996, Liedtke completò un dottorato di ricerca su tabelle di pagina custodite presso l' Università Tecnica di Berlino. ▪ Nello stesso anno si è unito al Thomas J. Watson Research Center , dove ha continuato a lavorare su L4 ▪ Nell'aprile del 1999 ha assunto la cattedra di System Architecture presso l' Università di Karlsruhe. ▪ Muore nel 2001 Jochen Liedtke 5
- 6. ▪ Nel 1992 inizia gli studi in Computer Science presso la Technische Universität Dresden e si laurea nel 1996 ▪ Continua quindi nel 1996 con un dottorato di ricerca nella stessa materia, completando nel 2002 ▪ Nel 1999, per 4 mesi, lavora come ricercatore presso Intel; stesso per il 2000 ▪ Nel 2002 fino al 2011 lavora presso lo staff di ricerca Intel sulla progettazione ed implementazione di tecnologie hypervisor e virtualizzazioni scalabili sicure, basate su microkernel ▪ Dal 2011 ad oggi copre il ruolo di Principal Engineer presso Intel, circa la smart analisys e IoT Sebastian Schönberg 6 «Oltre 10 anni di esperienza nella progettazione e nello sviluppo di piccoli micro-kernel, sistemi componentizzati e soluzioni di virtualizzazione (...) conoscenza di varie architetture CPU (Alpha, MIPS, SH3, IA32, ecc.); conoscenza interna nell'architettura di virtualizzazione IA32 di basso livello (VT)»
- 7. ▪ Forse la mente di Hermann? ▪ Pubblicazioni: ▪ 1995 : Emulation des UNIX- Proze?konzepts auf dem Mikrokern L3 ▪ 1996 : Flexible-sized page-objects ▪ 1997 : The performance of μ-kernel- based systems ▪ 1998 : DROPS: OS support for distributed multimedia applications ▪ 2005 : Fast Component Interaction for Real-Time Systems ▪ 2007 : Probabilistic Admission Control to Govern Real-Time Systems under Overload Jean Wolter 7
- 8. Indice ▪ Contesto Storico ▪ Kernel & Sistemi Operativi ▪ Microkernel & L4 Family ▪ L4Linux ▪ Extensibility Performance ▪ Compatibility Performance ▪ Conclusioni 8
- 9. Contesto Storico Evoluzione OS – 1 ▪ Anni 40 - 1st Generation ▪ Era molto complicato definire un OS ▪ Anni 50 - 2nd Generation ▪ General Motors Research Laboratories crea il 1° OS per IBM 701 ▪ Anni 60 - 3rd Generation ▪ Multiprogramming ▪ IBM presenta la serie di calcolatori System/360 9
- 10. Contesto Storico Evoluzione OS – 2 ▪ Anni 70/80 - 4th Generation ▪ LSI Tecnology ▪ I processori iniziano a diventare sempre più piccoli, grazie ai circuiti integrati ▪ Nasce il Personal Computer ▪ Anni 2000 - 5th Generation ▪ Sistemi Multicore 10
- 11. Contesto Storico Sistemi Operativi ▪ Un sistema operativo è un software che ▪ gestisce le risorse hardware (DRIVER) ▪ fornendo servizi di base (SYSTEM CALL) ▪ Garantendo protezione (LIVELLI DI PRIVILEGI) 11
- 12. Contesto Storico Qual è il problema? ▪ L’hardware avanza troppo velocemente ▪ I sistemi dell’epoca non appena uscivano era già obsoleti Vedi Disco: Running Commodity Operating Systems on Scalable Multiprocessors ▪ L’ottimizzazione del kernel non influenza più di tanto le prestazioni del OS (sarà poi confermato) Vedi The multikernel: A new OS architecture for scalable multicore systems 12
- 13. Contesto Storico Obiettivi della ricerca - 1 ▪ È possibile creare un kernel che possa rendere facile la portabilità di un sistema su più architetture? ▪ Se si, quanto inficia sulle prestazioni del OS? ▪ Costruire un OS basato su un microkernel (L4Linux) ▪ Metterlo a confronto con altri sistemi (Linux, MkLinux) 13
- 14. Contesto Storico Idea dei ricercatori ▪ Best possible performance ▪ Constraints: ▪ binary compatible with Linux/x86 ▪ minimal modifications 14 “What performance can we expect from an L4- based Unix system?” Objectives for L4Linux Ci ritorniamo presto …
- 15. Indice ▪ Contesto Storico ▪ Kernel & Sistemi Operativi ▪ Microkernel & L4 Family ▪ L4Linux ▪ Extensibility Performance ▪ Compatibility Performance ▪ Conclusioni 15
- 16. Kernel & Sistemi Operativi Cos’è un kernel? ▪ È la componente fondamentale di OS ▪ Fornisce un accesso sicuro all’hardware della macchina per i vari programmi ▪ Decide quando e per quanto tempo un programma può usare un determinato hardware 16
- 17. Kernel & Sistemi Operativi Quali servizi deve offrire un kernel? - 1 ▪ Comunicazione con Hardware ▪ Device driver, Dispatcher, … ▪ Schedulare i processi ▪ Scheduler ▪ Far comunicare i processi ▪ IPC, File System ▪ Accedere alla memoria ▪ VFS, Virtual Memory 17 Un kernel di un sistema operativo deve in genere permettere : Esempio di kernel monolitico
- 18. Kernel & Sistemi Operativi Quali servizi deve offrire un kernel? - 2 ▪ Nella comunità di ricerca c’erano battibecchi su cosa dovesse fare un kernel; vi erano 2 correnti di pensiero: Too Low ▪ Creare un kernel estensibile, mediante meccanismi per aggiungere funzionalità ai kernel pragmaticamente o sistematicamente Too High ▪ Approccio inverso, ci si concentra su come costriure una architettura hardware (standard) per usare l’interfaccia del kernel, garantendo portabilità e buona efficienza 18 Too high Too low
- 19. Kernel & Sistemi Operativi Tipologie ▪ Kernel Monolotici ▪ completa implementazione dell’astrazione hardware sottostante. ▪ Microkernel ▪ insieme ristretto e semplice di astrazione dell'hardware ▪ Kernel Ibridi ▪ l'implementazione di alcune funzioni aggiuntive rispetto a microkernel ▪ Exokernel ▪ NO all'astrazione dell'hardware, garantire solo l'accesso concorrente alle risorse 19
- 20. Kernel & Sistemi Operativi Kernel Monolotici - 1 ▪ I kernel monolitici sono un tutt’uno con il sistema che gestisce le risorse ed offre servizi; le parti sono una dipendente dall’altra ▪ Il sistema opera in funzione delle azioni che compie in 2 modi: ▪ User Mode ▪ Kernel Mode ▪ Per usufruire di un servizio si invoca un System Call ▪ La comunicazione tra i processi avviene in genere mediante IPC, a memoria condivisa 20
- 21. Kernel & Sistemi Operativi Kernel Monolotici - 2 ▪ PRO Ottima leggibilità del codice Chiamate molto efficienti usando IPC a memoria condivisa ▪ CONTRO Difficile da modificare Ricompilazione per ogni cambiamento Eccessive dimensioni Mancanza di estensibilità Poco manutenibile 21
- 22. Kernel & Sistemi Operativi Microkernel - 1 ▪ I microkernel hanno una struttura a livelli ▪ Kernel Level ▪ User Level ▪ Il kernel level è molto piccolo ed è composto da blocchi indipendeti che offrono funzionalità indispensabili al sistema ▪ System Call, IPC, Scheduler ▪ I restanti servizi invece sono implementati nel user level : rappresentano processi indipendenti chiamati server ▪ File System, Driver, Virtual Memory, … ▪ La comunicazione è in genere basata su scambio di mesaggi ▪ Il sender invia una messaggio al receiver 22
- 23. Kernel & Sistemi Operativi Microkernel - 2 ▪ PRO La comunicazione tra processi usa primitive di livelli sottostanti Espandibili e Modificabile Robustezza Portabile Adattabile a Sistemi distribuiti ▪ CONTRO Perdita di efficienza 23
- 24. Kernel & Sistemi Operativi Kernel Ibrido - 1 ▪ I sistemi ibridi sono combinazione di sistemi monolitici e sistemi a microkernel ▪ Hanno una struttura a microkernel ma implementata con un sistema monolitico ▪ Usa dei server separati per i servizi, ma sono incorporati a livello kernel ▪ Non ha una struttura ben definita 24
- 25. Kernel & Sistemi Operativi Kernel Ibrido - 2 ▪ Essendo una via di mezzo tra i due approcci, non possiamo definire a priori i suoi pro e contro 25
- 26. Kernel & Sistemi Operativi Exokernel ▪ Questo tipo di kernel ha un approccio completamente opposto a quelli precedenti.. ▪ Separazione protezione gestione delle risorse ▪ Si lascia al programmatore/compilatore la possibilità di gestire l’hardware garantendo sicurezza mediante opportuni strumenti 26 ▪ Il software parla con il kernel mediante primitive di piu basso livello ▪ Viene aiutato mediante delle libOS utilizzabili alle app ▪ Potrebbe emulare vari tipi di applicazioni eterogenee (es Win, Mac, Lin)
- 27. Kernel & Sistemi Operativi Perché non usare un kernel monolitico - 1 ▪ Quanto necessario ad usare il sistema e a fornirne un utilizzo ai programmi che vi girano è programmato in un unico programma (monolitico) che gira in kernel-space ▪ Non manutenibile, non portabile, non modulare. … ▪ È meglio usare un kernel piccolo con il minimo ed indispensabile, riscrivendo solo le parti hardware-dependent 27
- 28. Kernel & Sistemi Operativi Perché non usare un kernel monolitico - 2 ▪ Avere più componenti dipendenti (monolitico) risulta avere molto codice da manutenere, con possibilità maggiori di bug ▪ L’uso quindi di un microkernel è la naturale risposta a questa problematica ▪ ..e i ricercatori ci dimostrano tramite gli esperimenti che il gioco vale la candela. 28
- 29. 29The Tanenbaum-Torvalds Debate http://www.oreilly.com/openbook/opensources/book/appa.html «Io continuo a ritenere che progettare un kernel monolitico nel 1991 sia un errore fondamentale. Ringrazi che non è mio studente. Non avrebbe preso un voto alto per tale progetto» Andrew S. Tanenbaum
- 30. Indice ▪ Contesto Storico ▪ Kernel & Sistemi Operativi ▪ Microkernel & L4 Family ▪ L4Linux ▪ Extensibility Performance ▪ Compatibility Performance ▪ Conclusioni 30
- 31. Microkernel & L4 Family I microkernel L4 - 1 ▪ I microkernel, ed in particolare L4, si basa su due concetti principali: ▪ Thread ▪ Spazio di Indirizzamento ▪ La comunicazione mediante IPC è uno dei meccanismi fondamentali del microkernel ▪ Altre forme di comunicazione, come RPC e la migrazione controllata dei thread tra spazi di indirizzi, possono essere costruite da primitive IPC. 31
- 32. Microkernel & L4 Family I microkernel L4 - 2 ▪ Thread di L4 ▪ È un’attività eseguita all’interno di uno spazio di indirizzamento ▪ La comunicazione tra gli spazi di indirizzamento può essere implementate attraverso l’uso delle primitive IPC ▪ Possiede ▪ Spazio di indirizzamento ▪ Gestore di page fault (pager associato) ▪ Insieme di registri ▪ … ▪ L’associazione thread/spazio di indirizzamento è mantenuta dal microkernel 32
- 33. Microkernel & L4 Family I microkernel L4 - 3 ▪ Questo microkernel supporta la creazione ricorsiva degli spazi di indirizzamento in user level ▪ Lo spazio di indirizzamento iniziale sigma0 è gestito dal kernel ▪ A livello utente mediante funzioni grant, map, unmap è possibile gestire pagine logiche gerarchiche di dimensione 2^n ▪ Gli spazi di indirizzamento sono gestiti da server pager presenti in user level; quando di verifica un page fault il microkernel propaga via IPC al pager associato al thread che lo ha scatenato ▪ A differenza delle interrupt, le eccezioni e le trap sono sincrone alla generazione dei thread. Il kernel semplicemente li rispecchia ad user-level. 33
- 34. Microkernel & L4 Family I microkernel L4 - 4 34 Gestione dello spazio di indirizzamento Thread App Paginator Microkernel 1 2 3 Sequenza di eventi 1: Segnalazione Page Fault 2: Pager chiede al microkernel 3: Ripristino pagina
- 35. Microkernel & L4 Family Riepilogo Architettura L4 35 Hardware User Mode Ukernel Mode Drivers Programs Memory Man. Address Spacing Thread Man. IPC
- 36. Microkernel & L4 Family Implementazioni L4 Pentium – Alpha – MIPS ▪ Originariamente sviluppato per 486 e Pentium ▪ Esiste una implementazione L4/Alpha e L4/MIPS ▪ Come vedremo, bisogna cambiare "piccole" parti dipendenti dall’hardware del microkernel ▪ Algoritmi interni ▪ API binarie 36
- 37. Indice ▪ Contesto Storico ▪ Kernel & Sistemi Operativi ▪ Microkernel & L4 Family ▪ L4Linux ▪ Extensibility Performance ▪ Compatibility Performance ▪ Conclusioni 37
- 38. L4Linux Introduzione - 1 ▪ Molti sistemi classici emulano UNIX al di sopra di un microkernel. Ad esempio, i kernel monolitici UNIX sono portati sono portati su Mach e CHORUS. (vedi altri articoli) ▪ È stato scelto Linux per il porting su L4 ▪ Stabilità ▪ Buone performance ▪ OS standard de facto nel mondo dell’open source ▪ Rinuncia a modifiche strutturali al kernel Linux ▪ Mantenere “basso” lo sforzo del porting ▪ Mach ha dovuto modificare profondamente l’implementazione di Unix 38
- 39. L4Linux Introduzione - 2 ▪ Si avrà un lower bound alle prestazioni che si otterrebbero effettuando modifiche ed ottimizzazioni ▪ Il vantaggio è che versioni successive di Linux possono essere adattate ad L4Linux con poco sforzo 39
- 40. L4Linux Linux Essential ▪ È suddiviso in due parti: ▪ Architecture-dependent ▪ Architecture-independent 41 ▪ È stato eseguito il porting di Linux su qualsiasi tipo di architettura
- 41. L4Linux Metriche della creazione del porting Vincoli ▪ Piena compatibilità con linux, rendendo pienamente compatibili le componenti «off-the-shelf» ▪ Rimanere intatto L4, evitando modifiche ad-hoc per L4Linux ▪ Sui i vincoli sopra menzionati, la soluzione naturale è stata: ▪ i task microkernel sono usati dai processi utente Linux e forniscono i servizi Linux attraverso un singolo Linux server in un separato task microkernel. 42
- 43. L4Linux Linux Server ▪ Linux effettua un mapping 1-a-1 della memoria fisica verso lo spazio di indirizzamento del kernel ▪ Il server Linux richiede la memoria al pager sottostante ▪ Il server agisce da pager per i processi utente che crea 44
- 44. L4Linux Interrupt handling and device driver ▪ L4 gestisce gli interrupt hardware come messaggi (IPC) ▪ Il server Linux contiene thread che non fanno altro che attendere un messaggio di interrupt ▪ Priorità maggiore per thread di interrupt e thread bottom-half rispetto a quella del Linux server 45 Interrupt handling in L4Linux (Bottom Half) interrupt handler thread: do wait for interrupt { L4-IPC } top half interrupt handler () od Codice thread in attesa (Top Half)
- 45. L4Linux Linux User Process ▪ Ogni processo utente differente è implementato come un differente task L4 ▪ Possiede uno spazio di indirizzamento proprio in cui sono eseguiti i thread ▪ Per tutti i task viene creato dal Linux Server, il quale gestisce le loro pagine (pager) e qualsiasi page fault viene propagato come una RPC da L4 al Linux Server 46
- 46. L4Linux System Call Mechanism - 1 ▪ Le system call di L4Linux sono implementate usando RPC ▪ Esistono 3 interfaccie di chiamate a sistema utilizzabili : 1. Shared Library libc.so ▪ Usa le primitive IPC di L4 per invocare il Linux Server 2. Versione corrispondente modificata di libc.a 3. Trampoline ▪ Un gestore di eccezioni in user-level che emula la trap system-call nativa chiamando una corrispondente routine nella shared library modificata 47
- 47. L4Linux System Call Mechanism - 2 48
- 48. L4Linux Signal Delivery - 1 ▪ Il Linux kernel nativo invia le segnalazioni ai processi utente manipolando direttamente: ▪ Stack ▪ Stack pointer ▪ Instruction pointer ▪ L4 restringe le manipolazioni ai thread che condividono lo stesso spazio di indirizzamento ▪ Perciò, un addizionale gestore di segnali per thread è stato aggiunto ad ogni processo utente Linux … 49
- 49. L4Linux Signal Delivery - 2 50 Dopo aver ricevuto un messaggio dal server Linux, il signal thread fa sì che il main thread (eseguito nello stesso spazio di indirizzamento) salvi il suo stato ed entra in Linux manipolando lo stack pointer ed l’instruction pointer del main thread
- 50. L4Linux Scheduling ▪ Tutti i thread menzionati sopra sono schedulati dallo scheduler intero del microkernel L4. ▪ schedule() esegue il multiplexing del singolo thread del server Linux attraverso le multiple coroutine risultanti da chiamate concorrenti a system call. ▪ Al completamento di una system call, il server ▪ Riprende il corrispondente thread utente ▪ Resta in attesa di un nuovo messaggio di system call o di wakeup da parte di un thread di interrupt 51
- 51. L4Linux Supporto per Tagged TLB o Small Spaces - 1 ▪ Problema ▪ Lo switch di spazio di indirizzamento causa il flush della TLB ed implica alti costi di miss (seminario DISCO) ▪ Le tagged TLB evitano flush non necessari (anche qui usate) ▪ Pentium CPU: danno la possibilità di emulare il tagging della TLB per piccoli AS. ▪ Context switch frequenti nella TLB possono causare effetti simili ai flush 52
- 52. L4Linux Supporto per Tagged TLB o Small Spaces - 2 ▪ IDEA, il concetto di località ▪ Costruire piccoli, compatti, layout di spazi di indirizzamento dipendenti dall’applicazione possono aiutare ad evitare il conflitto menzionato. 53 CODE DATA Località ▪ SOLUZIONE ▪ L4Linux offre una speciale emulation library che permette la personalizzazione del codice e dati usati per la comunicazione con il server L4Linux.
- 53. L4Linux Il Risultato dell’adattamento L4Linux 54 Reused New Line
- 54. L’uso di un microkernel offre sostanzialmente anche altri due vantaggi non banali: ▪ Specializzazione ▪ implementazione migliorata di funzionalità particolari ▪ Estendibilità ▪ supporto a nuovi servizi non previsti e difficili da implementare nei sistemi operativi convenzionali ▪ database, real-time, multi-media,… 55
- 55. Indice ▪ Contesto Storico ▪ Kernel & Sistemi Operativi ▪ Microkernel & L4 Family ▪ L4Linux ▪ Extensibility Performance ▪ Compatibility Performance ▪ Conclusioni 56
- 56. Extensibility Performance 1. Possiamo aggiungere servizi esternamente ad L4Linux per migliorare le prestazioni specializzando funzionalità di Unix? 2. Possiamo migliorare alcune applicazioni usando meccanismi di microkernel nativi in aggiunta alle classiche API? 3. Possiamo raggiungere alte prestazioni per sistemi non- classici, incompatibili con Unix che coesistono con L4Linux? 57
- 57. Extensibility Performance Pipe & RPC ▪ IPC può essere implementato in modo significamente più veloce in un ambiente a microkernel che in un classico sistema monolitico ▪ Quattro varianti di scambio dati ▪ Meccanismo standard delle pipe fornito dal kernel Linux ▪ Pipe asincrone in L4 ▪ RPC sincrona ▪ Mapping RPC sincrono 58
- 58. Extensibility Performance Pipe & RPC - Meccanismo Standard delle pipe fornito dal Kernel Linux ▪ Cinque implementazioni: ▪ ( 1) gira su Linux/x86 nativo ▪ (1a) gira su L4Linux ed usa la libreria condivisa ▪ (1b) gira su L4Linux ed usa il meccanismo del trampoline ▪ (1c) gira sulla versione user-mode server di MkLinux ▪ (1d) gira sulla versione co-locata in-kernel di MkLinux 59
- 59. Extensibility Performance Pipe & RPC - Pipe Asincrone in L4 ▪ Pipe implementata a livello utente che gira direttamente su L4 ▪ Usa L4 per fare IPC e non necessita del kernel Linux. ▪ Pipe emulate rispettando lo standard POSIX 60
- 60. Extensibility Performance Pipe & RPC - RPC sincrona ▪ Utilizza IPC bloccanti ▪ Non effettua buffering di dati ▪ Non è semanticamente equivalente alle precedenti varianti, ma fornisce la semantica di RPC bloccante 61
- 61. Extensibility Performance Pipe & RPC - Mapping RPC sincrona ▪ Mittente mappa temporaneamente le pagine nello spazio di indirizzamento del ricevente ▪ Mapping visto come una forma speciale di IPC di L4 ▪ Può essere liberamente usato tra processi utente, safe: ▪ Richiede accordo tra mittente e destinatario ▪ Possono essere mappate solo le pagine del mittente 62
- 62. Extensibility Performance Pipe & RPC – Performance Table Results 63
- 63. Extensibility Performance Virtual Memory Operation - 1 ▪ Viene eseguito un test su di una operazione non presente in Linux nativo, viene quindi definito un Custom Pager ▪ Sono tabellati fault, ossia il tempo necessario a risolvere un page fault da parte di un pager definito dall’utente 64
- 64. Extensibility Performance Virtual Memory Operation - 2 ▪ Confronto di Linux con un implementazione dello stesso che usa i meccanismi nativi di L4 ▪ Trap ▪ Latenza tra un’operazione di scrittura in una pagina protetta da scrittura e l’invocazione del relativo gestore dell’eccezione ▪ Appel1 ▪ Tempo necessario ad accedere ad una pagina protetta scelta a caso ▪ Il gestore del fault non protegge la pagina, protegge altre pagine ed in seguito riprende l’accesso scorretto ▪ Appel2 ▪ Protegge 100 pagine ▪ Vi accede in una sequenza random, in cui il gestore dei fault protegge la pagina e riprende l’operazione che ha creato il fault 65
- 65. Extensibility Performance Virtual Memory Operation - 3 66
- 66. Extensibility Performance Cache Partitioning - 1 ▪ Le applicazione real-time necessitano di una gestione della memoria diversa da quella implementata su Linux. ▪ I pager user-level gerarchici consentono sia al sistema della memoria L4Linux che ad uno dedicato real-time di essere eseguito in parallelo. 67
- 67. Extensibility Performance Cache Partitioning - 2 PROBLEMA ▪ Applicazioni real-time si affidano ad uno scheduling "prevedibile" ▪ Schedulare il tempo del processore in maniera prevedibile è molto complicato in presenza di cache SOLUZIONE ▪ Partizionare la cache L2 tra task real-time ed applicazioni time- sharing usando un custom pager posto su L4 68
- 68. Extensibility Performance Cache Partitioning - 3 ESPERIMENTO ▪ moltiplicazione di matrici 64x64 interrotta periodicamente da un carico artificiale ▪ Senza interruzioni richiede 10.9 ms ▪ Interrotto ogni 100μs, caso peggiore 96.1 ms ▪ Con Cache Partitioning di 3 pagine di cache L2 allocate dal pager esclusivamente alla moltiplicazione tra matrici, su un totale di 64 (working set di 64 KB) ▪ Il tempo d’esecuzione del caso peggiore è ridotto a 24.9 ms, ossia un fattore di rallentamento di 2.29 69
- 69. Indice ▪ Contesto Storico ▪ Kernel & Sistemi Operativi ▪ Microkernel & L4 Family ▪ L4Linux ▪ Extensibility Performance ▪ Compatibility Performance ▪ Conclusioni 70
- 70. Compatibility Performance 1. Quanto costa l’uso di L4Linux anziché di Linux nativo? ▪ Confronto L4Linux e Linux nativo 2. Le prestazioni del microkernel sottostante sono importanti? ▪ Confronto tra L4Linux ed MkLinux 3. Quanto la co-location migliora le prestazioni? ▪ MKLinux usa un server co-located eseguita in kernel mode ed eseguito all’interno dello spazio di indirizzamento del microkernel, rendendo la comunicazione molto più efficiente tra processi-utente e processo/kernel ▪ Confrono MKLinux (co-located) vs L4Linux (non co-located) 71
- 71. 72
- 72. Compatibility Performance Measurement Methodology HARDWARE ▪ All measurements use the same Linux environment on one single machine: ▪ a 133 MHz Pentium PC ▪ based on an ASUS P55TP4N motherboard using Intel’s 430FX chip set, ▪ 256 KB pipeline-burst second-level cache ▪ 64 MB of 60 ns Fast Page Mode RAM ▪ Quantum Empire SCSI disk SOFTWARE ▪ microkernel L4,version 2 ▪ L4Linux based on Linux, version 2.0.2 ▪ MkLinux based on Linux 2.0.28 73
- 73. Compatibility Performance Tools and Methodologies ▪ Per il test vengono eseguiti due tipi di banchmark ▪ Microbenchmark ▪ Analizza il comportamento dettagliato dei meccanismi di L4Linux ▪ Macrobenchmark ▪ Misura le prestazioni generali del sistema 74
- 74. Compatibility Performance Microbenchmark - 1 ▪ Per una completa analisi delle penalizzazioni dovute quando si usa un microkernel, è stato usata la suite di benchmark Lmbench ▪ misura operazioni di base come systemcall, context-switch, accessi alla memoria, operazioni di pipe, operazioni di rete, che vengono ripetute un elevato numero di volte 75
- 75. Compatibility Performance Microbenchmark - 2 Interpretazioni ▪ penalizzazione piuttosto alta per l’uso di L4 ma è molto più bassa di quella per l’uso di Mach. ▪ per molti benchmark, l'uso di L4 rispetto a Mach è più prestante dell'effetto dell'utilizzo di un Mach co- located rispetto a un server in modalità utente 76
- 76. Compatibility Performance Macrobenchmark - 1 77 476 506 555 605
- 77. Compatibility Performance Macrobenchmark - 2 78 AIM multiuser benchmark suite VII ▪ Mostra le performance di sistemi multiutente in condizioni di alto carico applicativo ▪ Usa la libc.so condivisa ▪ Evita automaticamente trampoline System JobPerMin Linux 130 L4Linux 123 (93% nativo) MkLinux, User 81 (62% nativo) MkLinux, Kernel 95 (73% nativo) ▪ Misura il throughput raggiunto ogni volta che si aggiunge del carico ai vari sistemi, fino a determinare il throughput massimo
- 78. Compatibility Performance Macrobenchmark - 3 79 AIM multiuser benchmark suite VII
- 79. Compatibility Performance Riscontri 1. Quanto costa l’uso di L4Linux anziché di Linux nativo? ▪ I macrobenchmark indicano che l’implementazione di L4Linux è ragionevolmente vicina al comportamento di Linux nativo, con svantaggi del 5-10% 2. Le prestazioni del microkernel sottostante sono importanti? ▪ Entrambi i benchmark ne evidenziano l'importanza 3. Quanto la co-location migliora le prestazioni? ▪ Tutti i benchmark dicono che la co-location da sola non può sopperire alle mancanze del microkernel sottostante. MKLinux co-located ha prestazioni peggiori rispetto a L4Linux in user-mode. 80
- 80. Indice ▪ Contesto Storico ▪ Kernel & Sistemi Operativi ▪ Microkernel & L4 Family ▪ L4Linux ▪ Extensibility Performance ▪ Compatibility Performance ▪ Conclusioni 81
- 81. Conclusioni ▪ La prima generazione di microkernel era troppo lenta e poco flessibile ▪ La seconda generazione invece si è già dimostrata molto più promettente ▪ L4Linux VS Linux Native ▪ Throughput massimo solo 5% più basso di Linux ▪ L4Linux VS MkLinux ▪ I miglioramenti delle performance dei μ-kernel di seconda generazione influenzano le applicazioni del sistema operativo ▪ È possibile implementare un sistema operativo ad alte prestazioni al di sopra di un microkernel le cui performance sono cruciali per raggiungerlo ▪ il sistema risultante è altamente estendibile e che il concetto di estensione funziona bene. 82