| Red Hat Enterprise Linux 4: Introduzione al System Administration | ||
|---|---|---|
| Indietro | Capitolo 4. Memoria virtuale e fisica | Avanti |
Anche se la tecnologia usata al giorno d'oggi per la creazione delle varie tecnologie storage è notevole, un normale amministratore di sistema non ha necessità di conoscere tutti i vari dettagli. Infatti vi è solo un elemento che gli amministratori devono tener presente:
Non vi è mai abbastanza RAM.
Anche se questa affermazione potrebbe sembrare spiritosa, molti designer di sistemi operativi hanno lavorato moltissimo per ridurre l'impatto causato da questa carenza. Per far fronte a tale problematica hanno deciso d'implementare una memoria virtuale — un modo per combinare la RAM con una unità storage più lente, in modo da conferire al sistema più RAM di quella installata originariamente.
Iniziamo con una ipotetica applicazione. Il codice della macchina che crea la suddetta applicazione è di 10000 byte di misura. Sono necessari altresì altri 5000 byte per la conservazione dei dati e dei buffer I/O. Ciò significa che, per eseguire questa applicazione sono necessari 15000 byte di RAM; non un byte in meno, altrimenti l'applicazione non sarà in grado di essere eseguita.
Questi 15000 byte sono conosciuti come lo spazio dell'indirizzo dell'applicazione. Rappresenta il numero di indirizzi unici necessari per contenere sia l'applicazione che i dati. Nei primi computer, la quantità di RAM disponibile doveva essere maggiore dello spazio dell'indirizzo dell'applicazione più grande da eseguire; al contrario, l'applicazione compariva con un errore del tipo "out of memory".
L'approccio seguente conosciuto come overlaying ha cercato di trovare una soluzione a tale problema, permettendo ai programmatori di decidere in quale parte dell'applicazione potesse risiedere la memoria. In questo modo, il codice richiesto solo una volta per l'inizializzazione, poteva essere sovrascritto (overlayed) con quello da usare più in avanti. Mentre tale operazione è riuscita a facilitare in qualche modo la soluzione per la carenza di memoria, essa rappresentava un processo complesso e propenso ad errori. Tale approccio non era in grado altresì di trovare una soluzione per la carenza di memoria dell'intero sistema durante l'esecuzione dello stesso. In altre parole, un programma di tipo 'overlayed' potrebbe richiedere minor memoria per essere eseguito rispetto ad un programma non overlayed, ma se il sistema non ha memoria sufficiente per il programma 'overlayed', si avrà lo stesso risultato finale — un errore del tipo out of memory.
Con la memoria virtuale si pone il concetto dello spazio dell'indirizzo di una applicazione sotto un diverso punto di vista. Invece di sapere la quantità di memoria necessaria ad una applicazione per essere eseguita, un sistema operativo con memoria virtuale và alla ricerca continua"della quantità minima di memoria necessaria ad una applicazione per essere eseguita".
Mentre la nostra ipotetica applicazione necessita di tutti e 15000 byte per essere eseguita, cercate di ricordare l'argomento affrontato nella Sezione 4.1 — l'accesso della memoria tende ad essere sequenziale e localizzato. Per questo motivo, la quantità di memoria necessaria ad eseguire l'applicazione in ogni istante, è minore di 15000 byte — generalmente molto meno. Considerate i diversi tipi di accesso della memoria necessari per eseguire una istruzione singola della macchina:
L'istruzione viene letta dalla memoria.
I dati richiesti dall'istruzione sono letti dalla memoria.
Dopo il completamento dell'istruzione, i risultati della stessa vengono riscritti all'interno della memoria.
Il numero di byte necessari per ogni accesso della memoria varia a seconda dell'architettura della CPU, dal tipo d'istruzione e dei dati. Tuttavia, anche se una istruzione necessita di 100 byte di memoria per ogni tipo di accesso, i 300 byte necessari rappresentano una quantità molto inferiore ai 15000 byte dello spazio dell'indirizzo. Se si potesse trovare un modo per avere informazioni sui requisiti della memoria di un'applicazione durante l'esecuzione della stessa, sarebbe possibile mantenere una applicazione in esecuzione usando una quantità di memoria minore rispetto al suo spazio.
Ma tutto ciò fà sorgere una domanda:
Se solo parte dell'applicazione è presente nella memoria in ogni istante, dov'è il resto?
Una risposta a questa domanda è che il resto dell'applicazione rimane nel disco. In altre parole, il disco agisce come un backing store per la RAM; un mezzo per lo storage più grande e più lento, che funziona come un "backup" per un mezzo più piccolo e veloce. Questo potrebbe apparire un pò problematico in termini di prestazione — dopo tutto, le unità del disco sono molto più lente della RAM.
È possibile comunque trarre vantaggio dal comportamento sequenziale e localizzato delle applicazioni, eliminando molte delle problematiche inerenti le prestazioni nell'uso delle unità del disco come backing store per la RAM. Questo viene fatto intervenendo sul sottosistema della memoria virtuale, in modo da cercare di assicurare che le parti necessarie dell'applicazione — o che potrebbero essere utili in futuro —, siano conservate nella RAM solo per il tempo necessario.
Questo potrebbe essere simile al rapporto tra la cache e la RAM: e cioè combinando un tipo di storage piccolo e veloce, con uno più grande e più lento, comportandosi quindi come uno storage più grande e rapido.
Tenendo presente questo paragone, affrontiamo il processo in modo più dettagliato.