The performance of microkernel based system

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

Autori della ricerca
▪ Hermann Härtig
▪ Michael Hohmuth
▪ Jochen Liedtke (IBM)
▪ Sebastian Schönberg
▪ Jean Wolter

▪ 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

▪ 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

▪ 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

▪ 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)»

▪ 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

Indice
▪ Contesto Storico
▪ Kernel & Sistemi Operativi
▪ Microkernel & L4 Family
▪ L4Linux
▪ Extensibility Performance
▪ Compatibility Performance
▪ Conclusioni
8

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

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

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

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

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

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 …

Indice
▪ L4Linux
▪ Conclusioni
15

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

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

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

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

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

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

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

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

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

Kernel Ibrido - 2
▪ Essendo una via di mezzo tra i
due approcci, non possiamo
definire a priori i suoi pro e
contro
25

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)

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

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

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

Indice
▪ L4Linux
▪ Conclusioni
30

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

▪ 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

▪ 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
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

Riepilogo Architettura L4
35
Hardware
User Mode
Ukernel Mode
Drivers Programs
Memory
Man.
Address
Spacing
Thread
Man.
IPC

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

Indice
▪ L4Linux
▪ Conclusioni
37

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

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

L4Linux
Linux Essential
▪ È suddiviso in due parti:
▪ Architecture-dependent
▪ Architecture-independent
41
▪ È stato eseguito il porting di Linux su qualsiasi tipo di architettura

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

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

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)

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

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

L4Linux
System Call Mechanism - 2
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

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

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

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

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.

L4Linux
Il Risultato dell’adattamento L4Linux
54
Reused
New Line

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

Indice
▪ L4Linux
▪ Conclusioni
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

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

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

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

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

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

Pipe & RPC – Performance Table Results
63

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

▪ 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

66

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

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

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

Indice
▪ L4Linux
▪ Conclusioni
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

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

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

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

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

Macrobenchmark - 1
77
476
506
555
605

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

Macrobenchmark - 3
79
AIM multiuser benchmark suite VII

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

Indice
▪ L4Linux
▪ Conclusioni
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

The performance of microkernel based system

Recommended

Recommended

More Related Content

Similar to The performance of microkernel based system

Similar to The performance of microkernel based system (20)

The performance of microkernel based system