NACHOS - Appendice

A livello hardware

Forniamo un simulatore del disco, che accetta richieste di lettura e scrittura di settori del disco e segnala la fine dell'operazione attraverso una interruzione. I dati del disco sono memorizzati in un file UNIX; le operazioni di lettura e scrittura di settori del disco sono effettuate usando le normali funzioni UNIX di lettura e scrittura da file. Una volta che il file UNIX è stato aggiornato, calcoliamo quanto sarebbe dovuta durare l'operazione simulata (dalla traccia e settore della richiesta), e definiamo una interruzione che accadrà dopo quel lasso di tempo. Le richieste di lettura e scrittura di settori (che emulano l'hardware) ritornano immediatamente; il software di alto livello è responsabile per l'attesa dell'interruzione.

D.3.3 Multiprogrammazione

Nella terza esercitazione, forniamo il codice per creare uno spazio degli indirizzi utente, per caricare in memoria

utente un file Nachos che contiene un’immagine dell’eseguibile, per poieseguire il software. Il codice iniziale è limitato all’esecuzione di un solo programma utentealla volta. L’esercitazione ha come obiettivo di espandere questa base con il supporto per lamultiprogrammazione, di implementare una varietà di system call (come fork ed exec inUNIX) come anche una shell a livello utente, e di ottimizzare le prestazioni del sistemarisultante in un carico misto di jobs I/O e CPU-bound.Anche se forniamo una piccola porzione del codice del kernel Nachos come parte diquesta esercitazione, la simulazione hardware richiede una buona quantità di codice.Simuliamo l’intero set di istruzioni intere MIPS R2/3000 ed un semplice schema ditraduzione della tabella delle pagine ad un livello (per questa esercitazione, l’intero spaziovirtuale degli indirizzi del programma deve essere mappato nella memoria fisica; la veramemoria virtuale è

lasciata per la prossima esercitazione). Inoltre, forniamo una astrazione che nasconde la maggior parte dei dettagli del formato MIPS object-code. Questa esercitazione richiede alcuni salti concettuali, ma lega insieme il lavoro delle due precedenti esercitazioni, risultando in un sistema operativo – seppur limitato – funzionante. Dato che il simulatore è in grado di eseguire programmi in C, è facile scrivere software di utilità (come una shell o il comando UNIX cat) per testare il sistema (uno studente molto ambizioso ha provato ad effettuare un porting di emacs senza risultati). L’esercitazione illustra che scrivere codice utente non è molto difficile da scrivere codice del kernel del sistema operativo, sennonché il codice utente risiede in un suo spazio di indirizzi, isolando il kernel da errori dell’utente. Un importante argomento che abbiamo scelto di lasciare fuori (ancora, per una questione di limiti di tempo) è quello che

Riguarda la tendenza verso sistemi operativi a small-kernel, dove pezzi del sistema operativo sono divisi in server a livello utente. Grazie al design modulare di Nachos, sarebbe semplice migrare verso una struttura small-kernel, tranne che per:

1. Non abbiamo supporto per il debugging simbolico di programmi utente
2. Servirebbe un compilatore stub per rendere agevole l'uso di RPC attraverso diversi spazi di indirizzi

Un motivo per utilizzare un design a microkernel è indubbiamente quello della semplicità di debugging del codice di sistema operativo a livello utente invece di codice che è parte del kernel. Dato che Nachos viene eseguito come un processo UNIX, è valido il contrario: è più facile sviluppare e debuggare il codice del kernel Nachos rispetto al codice di una applicazione che viene eseguita da Nachos.

D.3.4 Memoria Virtuale

La quarta esercitazione prevede di rimpiazzare il semplice sistema di gestione della memoria dell'esercitazione

precedente con un vero sistema a memoria virtuale – un sistema chemostra ad ogni programma utente l’astrazione di una (quasi) infinita memoria virtualeusando la memoria principale come cache della memoria di massa. Non forniamo alcunnuovo hardware o componenti di sistema operativo per questa esercitazione.

L’esercitazione comprende tre parti. La prima parte tratta l’implementazione delmeccanismo per la gestione del page-fault – il kernel deve intercettare il page-fault, trovarela pagina richiesta sul disco, trovare una pagina in memoria per contenerla (scrivendo ilvecchio contenuto della pagina di memoria su disco se la pagina era in uso), leggere lanuova pagina dal disco in memoria, aggiornare la voce nella tabella delle pagine e poicontinuare l’esecuzione del programma. Questo meccanismo può avvantaggiarsi del codicescritto per le precedenti esercitazioni: la memorizzazione dello spazio

degli indirizzi può avvenire semplicemente utilizzando i file Nachos mentre la sincronizzazione è richiesta in caso di page-fault multipli concorrenti.

La seconda parte dell'esercitazione riguarda l'ideazione di una strategia per gestire la memoria come una cache - per decidere quali pagine scaricare su disco quando del nuovo spazio è richiesto, in che circostanze (se ci sono) fare read-ahead, quando scaricare le pagine piene non usate su disco e quante pagine caricare prima di eseguire un programma.

Queste questioni strategiche possono avere un grande impatto sulle prestazioni generali del sistema, in parte a causa della differenza tra velocità della CPU e latenza del disco - questa differenza è aumentata di due ordini di grandezza solo nella scorsa decade.

Sfortunatamente, le strategie più semplici spesso hanno prestazioni inaccettabili.

Per incoraggiare strategie realistiche, la terza parte dell'esercitazione consiste

nel misurare le prestazioni del sistema di paginazione con un programma di moltiplicazione di matrici, le quali non entrano in memoria. Questo carico non è rappresentativo del comportamento del sistema di paginazione nel mondo reale, ma è abbastanza semplice per illustrare l'influenza delle strategie sulle prestazioni delle applicazioni. Inoltre, il programma mostra molti dei problemi che si presentano con il caching: piccoli cambiamenti nell'implementazione possono avere grandi impatti sulle prestazioni.

D.3.5 Networking

La ciliegina sulla torta del progetto è scrivere una importante ed interessante applicazione distribuita. Abbiamo incluso questa componente del networking dato che le applicazioni distribuite stanno diventando, giorno dopo giorno, sempre più importanti commercialmente. A livello hardware, ogni processo UNIX che esegue Nachos rappresenta una macchina a singolo processore. Simuliamo il comportamento di una rete di macchine eseguendo

molteplici copie di Nachos, ognuna nel suo processo UNIX, ed usando i socketUNIX per passare i pacchetti tra le "macchine" Nachos. Il sistema operativo può comunicare con gli altri sistemi inviando pacchetti attraverso questa rete simulata; la trasmissione avviene attraverso le funzioni send e receive dei socket. Il network Nachos fornisce la possibilità di trasmissione non sicura di pacchetti dalla grandezza limitata da una macchina all'altra. La possibilità che dei pacchetti vengano persi (dropped) può venire settata attraverso la riga di comando, ed il seed può venire usato per determinare quali pacchetti sono "casualmente" scelti per essere persi. I pacchetti possono essere persi ma mai corrotti, quindi il checksum non è richiesto.

Per illustrare come usare il network ed, allo stesso tempo, illustrare i benefici della stratificazione (layering), il kernel Nachos è provvisto di un semplice protocollo post-office modellato

sopra il network. Il layer post-office fornisce una serie di caselle postali che dirigono i pacchetti al thread in attesa appropriato. I messaggi inviati attraverso il post-office contengono un indirizzo di ritorno che può essere usato per l'acknowledgement.

L'esercitazione richiede come prima cosa di implementare un sistema di trasmissione sicuro (reliable) di pacchetti di grandezza arbitraria, e poi di costruire una applicazione distribuita su questo servizio. Il supporto per la trasmissione di pacchetti dalla grandezza arbitraria è dalla semplice implementazione – si deve semplicemente suddividere qualsiasi pacchetto troppo grande in pacchetti più piccoli dalla grandezza fissa, aggiungere numeri di serie alle sezioni, ed inviare tutto pezzo per pezzo. Assicurare la sicurezza (reliability) è più interessante, richiede una attenta analisi e progettazione. Per ridurre il tempo richiesto per l'esercitazione,

non chiediamo di implementare un controllo di congestione né un window management, anche se ovviamente queste cose sono importanti nella progettazione di un protocollo. La scelta su come completare il progetto è lasciata aperta. Diamo solo alcuni suggerimenti: UNIX talk multi-utente, un file system distribuito con caching, una struttura di migrazione dei processi, memoria virtuale distribuita, un protocollo di gateway resistente ai crash delle macchine. Probabilmente, l'applicazione più interessante che uno studente ha scritto (di cui noi sappiamo) è stata una versione distribuita della "battaglia navale", con ogni giocatore su una "macchina" diversa. Questa applicazione illustrava il ruolo dello stato distribuito, dato che ogni macchina manteneva solo la sua vista locale della tavola di gioco; ha inoltre esposto molti problemi di performance nella simulazione hardware, che abbiamo risolto. Probabilmente, la più grande limitazione.

Un problema dell'implementazione attuale è che non sono state modellate le prestazioni del modello network correttamente, perché non manteniamo i timer di ogni macchina Nachos sincronizzati tra di loro. Stiamo lavorando per risolvere questo problema, usando tecniche di simulazione distribuita per questioni di efficienza. Queste tecniche ci permetteranno di effettuare paragoni di prestazioni tra diverse implementazioni del protocollo di network; ci permetteranno inoltre di usare il network Nachos come una simulazione di un multi-processore passa messaggi (message-passing).

Informazioni su Come Ottenere una Copia di Nachos

E' possibile ottenere una copia di Nachos attraverso il servizio di FTP anonimo della macchina ftp.cs.berkeley.edu seguendo i seguenti passi:

1. Utilizzare il comando ftp di UNIX per accedere a ftp.cs.berkeley.edu: ftp ftp.cs.berkeley.edu
2. Verrà richiesto di effettuare il login. Inserite la parola "anonymous" e poi usate il

Il tuo indirizzo email come password.

Name: anonymous

Password: tea@cs.berkeley.edu (for example)