The Dark Side of Hardware Upgrade Forum

Ai tempi degli 8086 la vita era facile... il concetto era "una CPU per un programma".
Di acqua sotto i ponti da allora ne é passata parecchia, e già con gli 286 ed il loro "protected mode" (così brutto e scomodo da non essere mai stato utilizzato da nessuno, a differenza di quello del 386) s'è cominciato a pensare "in un altro modo".

L'assunzione degli 8086 (ed in tutti i processori del tempo, dallo Z80 a scendere) era che ci fosse un solo programma in esecuzione e che questo potesse accedere e gestire a tutte le risorse.
Anche MSDOS (l'OS "tipico" per gli x86 del tempo) alla fine era solo un insieme di funzioni "disponibili" al programma (con "il programma" command.com quando si era al prompt); quando eseguivi "un altro programma" il command.com veniva "messo da parte" (se non addirittura "cancellato" dalla memoria) e si eseguiva il programma indicato... a fine "programma" la "funzione" di "fine programma" ripuliva un po'la memoria e rieseguiva il command.com.

Ovviamente s'è sentito abbastanza presto il bisogno di passare a modelli più "pratici" nei quali fosse possibile eseguire contemporaneamente diversi programmi, ma per poterlo fare è stato necessario un complesso "salto" in avanti... non solo nei sistemi operativi ma nel come sono strutturate le CPU.

C'è una quantità di assunzioni importanti da fare per poter parlare di sistemi operativi multitasking, e molte di esse hanno ramificazioni profonde che portano a precise scelte nell'hardware... qui cercheremo d'essere esaustivi senza però fissarci su ogni punto... in un futuro apposite guide e/o approfondimenti tratteranno nel dettaglio quei campi.

Ma andiamo con ordine...

Come fanno due programmi a stare contemporaneamente in memoria ?
Devono essere fisicamente ambedue presenti nella RAM nello stesso momento... ed ovviamente (per la legge dell'incompenetrabilità dei corpi ) devono essere in due punti diversi della memoria.
Voi direte "ok, basta avere abbastanza memoria" ma purtroppo non è così semplice.

Una prima considerazione è che se ammetto più programmi in memoria contemporaneamente non posso sapere (quando compilo il codice) DOVE il codice verrà scritto, ragion per cui gli accessi diventano molto più complicati (esempio pratico... se il mio programma può essere messo in una qualsiasi posizione da 0 a 10.000 come faccio a caricare su registro un dato dalla memoria ? non ho modo di conoscere il suo indirizzo in memoria fino a quando non verrà eseguito).
Una seconda considerazione è legata all'"economia" della memoria... ovvero, se ho tre programmi (A, B e C) di, rispettivamente, 500, 500 e 600K ed una memoria di 1200K (è un esempio eh):
A tempo 0 avvio A e B (che vengono "eseguiti" rispettivamente nella memoria da 0 a 500K ed in quella da 500K a 1000K)
Il programma A termina, mi ritrovo con un area di memoria libera da 0 a 500K ed un altra libera da 1000 a 1200K.
e provo a lanciare C... ma non ho DOVE eseguirlo, perché pur avendo 700K di memoria libera non ho abbastanza memoria CONTIGUA per mettere il programma.
Una terza considerazione è di "sicurezza": se due programmi sono contemporaneamente in memoria uno dei due potrebbe (per errore o "volontariamente") leggere/scrivere frazioni di codice dell'altro programma.

Questi "problemi" legati alla memoria sono "tipici", ampiamente studiati ed ampiamente risolti con le tecnologie odierne... e tuttavia per poter essere affrontati e risolti occorre che la CPU metta a disposizione degli strumenti specifici.
Questa è una dipartita da quanto abbiamo visto finora... finora abbiamo parlato delle CPU solo dal punto di vista prestazionale... qui cominciamo a vedere che per essere effettivamente "utili" oltre che "veloci" devono essere anche "versatili", e vedremo che questa "versatilità" ha il suo prezzo.

Apriamo una piccola parentesi... finora abbiamo parlato di "programma" ma il termine è improprio... un programma è il file eseguibile.
Quando il "programma" viene "scritto" in memoria ed eseguito si parla più correttamente di "processo".
Perché questa precisazione ? Perché "format.exe" è un programma mentre la formattazione del disco "C" è un processo e la formattazione del disco "D" è un altro processo.
Il programma che li ha generati è lo stesso ma i due processi sono distinti, operano su risorse distinte e sono grossomodo indipendenti l'uno dall'altro.
Fine della parentesi.

Vediamo innanzitutto come s'è risolto il problema degli indirizzi.

Il primo problema, a dire il vero, era già presente anche sui sistemi stile MSDOS, tant'è dei modi per "aggirare" la limitazione sono sempre esistiti.

Un modo per aggirare il problema è quello di non usare indirizzi "assoluti" (cioè non usare istruzioni tipo "LOAD a0,indirizzo" ) ma "relativi" all'indirizzo di codice che si stà usando o ad un registro da usare come "base" per le locazioni di memoria (tipo "LOAD a0,[ip + 4000]" o "LOAD a0,[d0 + 32]"). Ovviamente per "funzionare" la cosa và estesa anche a tutte le istruzioni di salto, condizionato o incondizionato.

Una seconda "tattica" è quella di rendere "implicito" lo scostamento, che poi è il modo utilizzato dagli 8086.
In pratica la CPU calcola gli indirizzi usando due registri e sommandone i valori.
Ogni registro, "di default" si appoggia ad un particolare registro detto "segmento" (IP si riferisce a CS, i registri dati a DS, lo stack ad SS e così via).
In questo modo il processo verrà eseguito sempre nelle stesse locazioni, quello che potrà cambiare è il valore all'interno del registro di segmento.

Questi sistemi hanno i loro vantaggi ed i loro svantaggi ed in generale il primo sistema è usato ancora oggi (il codice scritto in questo modo viene detto "PIE" o Position Independent Executable ed è impiegato, ad esempio, nelle librerie di alcuni SO... notabilmente le DLL ed in alcuni sistemi che sfruttano ASLR).

Più problematico risolvere gli altri problemi.
In diversi ambiti (tipicamente sulle CPU RISC) il terzo problema (l'isolamento dei processi) è stato risolto indicando in registri "speciali" degli intervalli di memoria entro il quale un programma può effettuare letture/scritture/salti.

Fermiamoci un attimo, questo è un grosso passo in avanti.
Abbiamo appena introdotto, in modo abbastanza defilato, un concetto che oggi e ubiquo nelle architetture e nei sistemi operativi... il concetto di "privilegio".
Detta in modo molto semplice abbiamo appena stabilito che la CPU può lavorare con dei "limiti" aggiuntivi imposti dalla CPU stessa.
In pratica questo significa che il sistema operativo prima di eseguire un programma predispone la CPU stessa per operare con "poteri limitati" al fine di tutelare sé stesso e gli altri processi.
Viene da sé la CPU può funzionare in due (o più) modi:
un modo privilegiato (detto anche "supervisore") in cui "ogni cosa è lecita" ed un modo non privilegiato (detto anche "user", che in italiano sarebbe "utente") in cui la CPU ha diversi limiti che non può infrangere.
Il passaggio da un modo all'altro è possibile attraverso alcuni meccanismi pensati appositamente per impedire violazioni.
Ad esempio, tornando al nostro discorso, un processo user non può scrivere al di fuori dell'area a lui assegnata, e non può modificare (direttamente) i limiti di tale area.

E se avesse bisogno di "spazio extra" ?
In quel caso può effettuare una richiesta al sistema operativo.
In linea di massima la richiesta non sarà altro che un messaggio che un frammento di codice eseguito in modo "supervisore" valuterà ed eseguirà se "ragionevole".
In caso positivo sarà il frammento di codice "supervisore", che è altrove, al di fuori del processo utente, a modificare i limiti entro il quale il processo richiedente può agire.
Analogamente una qualsiasi operazione privilegiata in modo utente provocherà il blocco del processo e l'invio di un messaggio (che prende il nome di "eccezione") all'apposito gestore in modo "supervisore"... e starà il gestore a decidere "cosa fare" (e tipicamente terminerà forzosamente il processo).

E già qui vi rendete conto di come i processori si siano dovuti espandere e modificare per poter accomodare un evoluzione dei sistemi operativi.
Mentre proseguiamo a parlare della memoria e di come la sua gestione si sia affinata negli anni (per poi vedere quali sono i risvolti dal punto di vista tecnico) tenete sempre presente i concetti di processo e di "modo" perché saranno determinanti per capire come si comporta una CPU e perché si comporta in un certo modo.

wtf?

Chi non ha basi di assembly si attacca? Io mi son perso quando hai iniziato a parlare di registri e per sigle

I registri sono essenzialmente celle in cui stanno i dati... non c'è molto da capire.
Per fare un rapido parallelo le tue mani possono essere due registri... la tua scrivania può essere la cache, la libreria in camera tua la RAM.
In pratica tu puoi leggere (e scrivere) solo quello che è nelle tue mani, quindi qualsiasi libro (dato) dev'essere nelle tue mani per poterci lavorare...
(i libri invece stanno tutti normalmente nella libreria, ma quelli che t'occorrono più urgentemente li puoi spostare sulla scrivania, dove sono più facili da raggiungere... pur "mantenendo" un loro posto "ufficiale" nella libreria)
Ovviamente "il loro posto" non è "le tue mani" ma la tua libreria.
Il "lavoro" delle CPU è essenzialmente quello, leggere e scrivere sulla roba che stà nella libreria, ma i dati non possono essere letti o scritti se non sono nelle tue mani.
I registri sono essenzialmente questo, il "posto" dove stanno i dati che vengono "elaborati".

Facciamo un esempio... un libro di architettura ti spiega come fare un campanile (codice), un fascicolo ti dice quali sono i limiti architettonici del campanile che devi fare (dati) ed una risma di carta è il posto in cui metterai il progetto compiuto.
La CPU (tu) devi leggere dal libro i passi necessari, rapportarli ai dati presenti nel fascicolo e scrivere sui fogli i passi intermedi ed il progetto finale... per fare ciò devi continuamente "prendere in mano" diverse cose e riporne altre.

I registri sono questo, l'equivalente delle "mani".

I registri "visibili" sono quelli che il programma può dire di usare (aka "mano destra" in "metti nella mano destra il fascicolo del capitolato, capitolo dei materiali dei mattoni, pagina 3") quelli "invisibili" invece sono dei "posti" in cui i libri "passano" durante l'esecuzione dei comandi (ad esempio "sotto l'ascella")... la differenza è che tu hai solo due mani, le CPU ne hanno molte di più.

Per "compatibilità" gli Intel hanno mantenuto l'infrastruttura a segmenti sull'estensione a 32bit, per cui tutti i processori Intel x86 e derivati/cloni in modo a 32 bit utilizzano ancora i segmenti (anche se in maniera leggermente diversa).

(spiego in breve come giusto per praticità)
Nella pratica nel registro di segmento (che in modo "32 bit" meglio noto come "protected mode" o "modo protetto" si chiama "selettore") stà un valore che indica un elemento di una specifica tabella (ogni processo ha due tabelle, una globale e quindi comune a tutti i processi ed una locale al processo); nella tabella sono indicati (fra le altre cose) l'indirizzo fisico iniziale e la dimensione del segmento.
Quando il programma scrive un valore in un registro selettore la CPU recupera i dati relativi a quel segmento dalla relativa tabella ed usa i valori "base" e "limite" ad ogni accesso relativo a quel selettore.
Questa soluzione è molto elegante (anche perché nella tabella è possibile definire molti altri valori che incidono su come la CPU utilizza quel segmento) ma non risolve del tutto il problema della frammentazione dello spazio libero e richiede che l'OS si faccia carico di gestire anche le tabelle.
Il problema della frammentazione diventa più "gestibile" perché è possibile "mettere in pausa" il processo, spostare fisicamente i dati del segmento nella memoria in modo da limitare la frammentazione, risistemare il valore del campo "base" nella tabella di segmento e "riavviare" il tutto... solo che il lavoro di "rilocazione" diventa molto pesante (pensate ad un segmento di 60MB, per "rilocarlo" bisogna leggere e scrivere 60MB, il che vuol dire impegnare CPU e RAM per un certo tempo senza "produrre" nulla).

Per questo tutti i sistemi operativi si sono rivolti "altrove" e, alla fine, l'ha capito anche Intel (o meglio, gliel'ha fatto capire AMD quando ha fatto gli x86_64 ed ha messo uno statuario "a 64 bit i selettori hanno tutti indirizzo di base 0 e limite 0xFFFFFFFFFFFFFFF" al quale Intel s'è dovuta adeguare).
La soluzione (che, peraltro, Intel aveva già abbracciato sugli x86 insieme alla segmentazione) è la paginazione... un sistema molto più dispendioso dal punto di vista della complessità del SO ma che risolve in modo definitivo qualsiasi problema di frammentazione.

Quando si abilita la paginazione la memoria viene vista come pagine di una dimensione prefissata (es.4K) ed ogni indirizzo (detto "indirizzo paginato") risulta composto da due parti, il suo numero di pagina e l'indirizzo all'interno della pagina.

Per capirci... una pagina di 4K (4096 byte) ha bisogno di 12 bit per essere indirizzata (2^12 = 4096), per cui se ho un indirizzo di 32 bit i 12 bit più bassi vengono usati come "indirizzo" all'interno della pagina ed i restanti 32-12 = 20 bit sono l'indirizzo di pagina.
Da qualche parte in memoria (nella memoria fisica, senza considerare gli indirizzi di pagina) c'è la tabella delle pagine che indica la posizione nella memoria fisica della pagina relativa... i dati dell'n-esima pagina saranno l'n-esimo elemento di quella tabella.
Ogni volta che si effettua una lettura o una scrittura la CPU "traduce" l'indirizzo paginato in un indirizzo fisico.

E questo in che modo risolve il problema ?
Semplice... ogni processo avrà IL SUO spazio d'indirizzamento paginato (ovvero la sua tabella di paginazione), per cui ogni processo vedrà la memoria in modo uniforme senza problemi di frammentazione mentre l'OS si occuperà di allocare le pagine a questo o a quel processo nel modo più efficiente possibile.
Un "bonus" facile è che basta rendere visibile la stessa pagina in due processi per ottenere una "finestra" attraverso la quale i due processi possono "comunicare" l'un l'altro.

(continua questo pomeriggio)

In B4 CR3

Ecco, ad esempio, come funziona(va) la paginazione sugli x86:



Gli x86 non usano un sistema con un unica tabella delle pagine... e questo per questioni di "spazio": 2^20 bit sono 1MB indirizzi, cioè oltre un milione d'elementi di pagina... se un puntatore di pagina fosse anche solo 4 byte vorrebbe dire che ogni processo, anche quello più piccolo, richiederebbe 4MB di RAM per la sola tabella di pagina (che, oltretutto, dovrebbe essere preparata).
Per questa ragione s'è deciso di usare (più o meno ovunque) un sistema a due o più livelli.
Nella pratica vuol dire che l'indirizzo di pagina è a sua volta diviso in due o più parti che vengono "elaborate" in sequenza fino ad arrivare all'indirizzo di pagina effettivo.
Nel caso di cui sopra il primo livello non contiene indirizzi di pagina ma degli indirizzi alle tabelle di secondo livello mentre le tabelle di secondo livello contengono gli indirizzi di pagina.
Il vantaggio è che gli elementi di primo livello possono essere marcati come invalidi, in questo modo non occorrerà allocare le corrispettive tabelle di secondo livello.

Con l'evoluzione i processori x86 hanno avuto a disposizione anche un modo ad indirizzamento "diretto" e pagine da 4MB:



...un sistema "un po'modificiato" a pagine da 2MB per gestire spazi d'indirizzamento fino a 256TB:



...ed infine un sistema con pagine da 4K (come quello "classico") con un livello addizionale che permette di gestire spazi d'indirizzamento maggiori:



...quest'ultimo è quello attivo di default per Windows quando si usa NX.

Per la cronana: CR3 (Control Register 3) è il registro che contiene l'indirizzo alla tabella delle pagine.

Oh, ed ecco com'è fatta una page entry "attualmente" (quell'EXB in cima è l'execute disable" bit):


Come si nota facilmente EXB è nella parte "estesa", per questo l'NX è attivabile solo sui processori che supportano PAE.


Altri sistemi hanno usato altri "tagli" (a seconda della dimensione delle tabelle di livello etc.) ma più o meno tutti i processori moderni usano la paginazione (tranne il chip della PSP, che per l'appunto è solo un giocattolo ).

Da notare che questo sistema diventa molto pesante dal punto di vista delle iterazioni con la memoria... si arrivano a fare ben quattro operazioni per poter effettuare una lettura/scrittura (e, mano a mano che si studia il dettaglio, si vede che il numero aumenta), per cui è necessario trovare un modo per ridurre l'overhead... ovvero riciclare il concetto di cache.
Ebbene si, le cache esistono anche per la paginazione (e per la segmentazione)... solo che anziché byte o pagine queste cache specifiche (genericamente chiamate TLB, Traslation Lookaside Buffer) funzionano a elementi di tabella.
Al di fuori di questo "piccolo" dettaglio le cache TLB sono essenzialmente identiche alle cache "normali", con tanto di doppio livello (L1 e L2).
Se poi voleste sapere "should I care ?"... beh, vi ricordate il bug dei Phenom ? Era un errore di progettazione nelle cache TLB... e la soluzione era sostanzialmente disabilitare parte delle funzionalità di queste cache, col risultato di una perdita prestazionale di almeno il 10%.

Fate un po'voi i conti.

interessante

post splittati, per Q&A usate questo thread: viewtopic.php?f=5&t=22940

Ora per un attimo mettiamo da parte il lato della memoria e parliamo di un altro argomento importante, gli interrupt.
Non è un volo pindarico, è che molte cose che inseriremo con gli interrupt torneranno utili quando riprenderemo la memoria.

Ora, un interrupt è una cosa semplicissima, in pratica è un segnale che un qualsiasi device invia al processore.
Visto che i dispositivi sono asincroni (vanno per fatti loro) è infatti necessario trovare un modo per ottenere "l'attenzione" della CPU.

Tempo addietro (o in condizioni molto particolari oggi) si usava una tecnica chiamata "polling" in cui la CPU controllava ciclicamente i device e vedeva se c'erano stati dei cambiamenti nel loro stato... ma questo sistema impegnava troppo tempo del processore e la programmazione diventava difficile, per questa ragione si sono sviluppati gli interrupt.

Un interrupt è in pratica un segnale elettrico (IRQ, Interrupt request, richiesta d'interrupt) mandato alla CPU... quando la CPU lo riceve ferma il processo corrente, ne salva lo stato e và ad eseguire un frammento di codice speciale chiamato genericamente "ISR", Interrupt Service Routine.
Gli ISR sono generalmente eseguiti in modo supervisore, tuttavia non è raro che un ISR si limiti ad "attivare" un processo (nel caso in cui la gestione del device che ha generato l'interrupt abbia un suo processo).
Gli ISR si concludono ripristinando lo "stato" del momento in cui l'IRQ è arrivato e riesumando quindi il lavoro che stavano facendo prima che arrivasse l'IRQ.
Una CPU può avere un numero qualsiasi (deciso dal costruttore) d'interrupt, e gli interrupt possono anche avere diverse priorità, sovrapporsi, essere condivisi e via dicendo... tutto stà a come è fatta la CPU ed a come il SO la utilizza.

Ecco, ed ora devo smentirmi
Alcuni interrupt non sono affatto "esterni", in diversi casi gli interrupt possono anche essere provocati direttamente o indirettamente dalla CPU ed addirittura dal codice stesso.

Per evitare ambiguità in genere, pur essendo gestiti nella stessa maniera (o quasi) il termine "interrupt" si associa a quelli generati da dispositivi esterni alla CPU mentre quelli generati "in loco" vengono chiamati "eccezioni".

Un esempio classico d'eccezione è quella che viene invocata quando si esegue un operazione di divisione ed il divisore è 0... in questo caso non è possibile eseguire normalmente la divisione e l'unico modo per "avvertire" che c'è qualcosa che "non va" è far scattare l'eccezione.

Un esempio "un po'meno classico" d'eccezione è quella che viene invocata quando si prova ad accedere ad una pagina la cui corrispondente page entry marca come non presente (o se si prova a scrivere in una pagina "read only").

Un esempio "ancora meno classico" d'eccezione è quella che viene invocata quando si è verificato un problema veramente grave ed è impossibile continuare ad eseguire il processo (ad esempio se si prova ad eseguire codice in una pagina "not executable").

Per le eccezioni "utente" (divisione per zero e simili) ogni processo viene generato con un "sotto-ISR" che viene chiamato dall'ISR vero e proprio e che gestisce l'evento "localmente" mentre le eccezioni "di sistema" sono normalmente "invisibili" ai processi.

Piccola nota a latere: In molti OS (dal vetusto MSDOS a Linux) il processo invoca esplicitamente un eccezione per comunicare con il sistema operativo.

Fra gli interrupt veri e propri invece bisogna distinguere fra due tipi: gli interrupt normali ed il famigerato NMI.

Gli interrupt normali sono quelli che vengono eseguiti normalmente; tipicamente quando un interrupt è in esecuzione o in particolari frammenti di codice "critici" eventuali interrupt "successivi" vengono "messi in pausa"... l'NMI (Non Maskable Interrupt) invece ha sempre la precedenza e... interrompe anche gli interrupt!
La ragione è insita nel fatto che in genere un NMI viene invocato solo in casi di estrema necessità, di solito legati a malfunzionamenti dell'hardware.

In tutti i processori moderni la CPU ha al suo interno un registro che contiene l'indirizzo alla tabella degli interrupt, una tabella in cui ogni elemento è a sua volta un puntatore ad un ISR, in altri casi (con CPU particolarmente "grezze" o "datate") invece la tabella degli interrupt è messa in una posizione fissa della memoria (sugli x86 a 16 bit la tabella è messa da 0 in poi, sugli x86 a 32 bit invece c'è l'apposito registro IDTR).

Giusto per nota vale la pena ragionare nell'ottica che in alcune architetture (nei Motorola 680x0) l'unità che si occupava della paginazione era un chip esterno (il 68851)... per cui il ricorso agli interrupt era ovvio.
Oggi si è fortunatamente deciso di mettere la l'unità che gestisce la paginazione (detta MMU, Memory Management Unit) direttamente "dentro" la CPU, per cui alcune cose sono cambiate... ma non il funzionamento di fondo.

Torniamo a noi.
In un entry di pagina ci sono molti campi che, se usati bene, possono essere MOLTO utili; nei post precedenti abbiamo visto alcuni di essi e come è strutturata un entry di pagina x86... beh, molti dei "giochi" più interessanti si fanno sfruttando i campi extra della paginazione.

Il primo campo che salta all'occhio (ed il primo che abbiamo visto) è il campo "presente" che ci dice se effettivamente la pagina c'è o meno.
Se la pagina è presente allora la decodifica avviene normalmente mentre se la pagina è assente parte l'apposita eccezione... dov'è la cosa simpatica ?
Beh, finora noi abbiamo supposto che le pagine "assenti" fossero quelle che non sono state allocate per il processo, e invece c'è un altra possibilità... una pagina assente potrebbe semplicemente "esistere" ma essere "assente" dalla memoria. Entra in gioco il concetto di swap.
Se ho bisogno di memoria ed ho molti processi con la paginazione posso infatti spostare le pagine meno usate su un dispositivo di massa (i.e. sull'hard disk) e liberare memoria fisica per... altre pagine; il trucco stà nell'indicare la pagina spostata sul disco (swap out) come assente nella page entry.
Quando il processo andrà ad accedere alla pagina "assente" avverrà un eccezione e l'ISR (ESR ?) si occupererà di rimettere la pagina assente "da qualche parte" (swap in) e risistemare il page entry riavviando il processo subito dopo.

Un altro campo d'un certo interesse è il campo writeable (o readable), mediante questo flag si può programmare la CPU per invocare un eccezione ad ogni lettura/scrittura...
...l'utilità di questo flag (oltre che per la sicurezza, infatti il codice dovrebbe essere tutto "read only") è che si possono indicare porzioni di memoria come "area messaggi" per cui una scrittura o una lettura possono essere intercettate dall'ISR e gestite come l'invio/l'attesa di un segnale da parte di un altro processo.

Altri campi (dipendenti dall'architettura in uso) possono essere:
* il bit "anchor" ("ancorato") che indica esplicitamente (più all'OS che alla CPU) che la pagina contiene codice di sistema (ad esempio un ISR) o locazioni particolari (ad esempio per l'accesso memory mapped) e che quindi non può essere soggetta a swap out o a spostamenti,
* il bit "supervisor" che indica che la pagina può essere letta/scritta/eseguita solo quando la CPU è in modo supervisore,
* il bit "not exectutable" (peraltro già visto) che indica che la pagina non può contenere codice,
* il bit "dirty" ("sporco") che viene posto ad 1 quando la CPU scrive nella pagina (il vantaggio è che se la pagina è presente anche nello swap e dirty=0 non c'è bisogno di riscriverla nello swap durante lo swap out),
* il bit "accessed" che viene posto a 0 dall'OS quando la pagina viene creata o dopo lo swap in e viene messo ad 1 al primo accesso alla pagina (utile per la gestione delle pagine),
* eventuali bit di caching che disabilitano il caching della pagina o forzano il write through
...e così via.

La CPU si trasforma quindi da un sistema "monolitico" tipico degli OS capaci di eseguire un solo processo alla volta (stile MSDOS) ad un sistema "ad eventi" in cui l'OS oltre a svolgere le funzioni "comandate" dal processo si occupa di una serie di compiti "trasparenti" al processo che rendono la macchina più efficiente.

PS: Generalmente quando la pagina è "non presente" gli altri campi della sua entry sono ignorati dalla CPU per cui l'OS può usare il resto dell'entry per metterci dentro un valore utile a "recuperare" la pagina dallo swap.

bella spiegazione quella degli interrupt

Abbiamo parlato molto degli ISR, ma dove sono ubicati "veramente" ?
Tipicamente, per evitare "rogne", il sistema operativo (ISR, tabella del processo e compagnia bella) sono messi staticamente al fondo dello spazio paginato (aka alla fine della memoria "per come il processo la vede").
Questo spiega perché le entry di pagina in genere hanno un flag che inibisce l'accesso in modalità "non supervisore"... è semplicemente "più pratico" mettere gli ISR nello stesso spazio d'indirizzamento piuttosto che dover disabilitare la paginazione o dover passare da uno spazio d'indirizzamento all'altro per ogni processo.

Ma nonostante questi accorgimenti un interrupt rimane un evento traumatico che, ove possibile, và limitato.
La ragione è che le pagine dell'ISR spesso non sono in cache, e comunque quando si esegue un interrupt la CPU deve salvare il suo stato (e sono un certo numero d'istruzioni di scrittura in memoria) e recuperarlo alla fine dell'ISR (e sono altrettante operazioni di lettura).
A questo problema si aggiunge un secondo discorso, altrettanto pesante... molti device (hard disk, cdrom) hanno bisogno di spostare da/verso la RAM quantità "rilevanti" di dati... e questi dati arrivano in modo asincrono.
La "dottrina" interrupt offre solo due soluzioni... o si richiede un interrupt per ogni dato o, arrivato il primo interrupt, la CPU "rimane" nell'ISR a inviare/recuperare tutti i dati che compongono il "blocco" a mano a mano che arrivano/si possono inviare.
Nessuna di queste soluzioni è elegante... e men che mai efficiente. Si è quindi escogitato un modo più furbo per risolvere questo genere di problema.

In pratica si sono aggiunti dei processori stupidissimi nelle schede madri, i DMAC (Direct Memory Address Controller).

Un DMAC è un processore che fa solo una cosa... spostare dati.
L'hardware dei device è leggermente modificato, nel senso che anziché un interrupt alla CPU i device "comunicano" con il DMAC ed il trasferimento vero e proprio lo fa il DMAC senza dar fastidio alla CPU (che al più può dover aspettare qualche ciclo in più quando prova ad accedere alla RAM e la trova "già impegnata" dal DMAC).

Ma quant'è stupido il DMAC ?
Il DMAC è MOLTO stupido... la singola unità (un computer ne ha diverse) si limita a rispondere alle richieste che gli arrivano ma DA DOVE leggere o DOVE scrivere sono cose che deve dirgli qualcun'altro.
Nella pratica è sempre la CPU a dover "programmare" il DMAC dicendogli che operazione fare (DALLA memoria, ALLA memoria, DALLA memoria ALLA memoria) dove prendere i dati e dove lasciarli.
Quindi schematicamente programmare un DMAC è:

1. impostare l'indirizzo da cui leggere/scrivere i dati
2. indicare quanti dati leggere/scrivere
3. indicare su quale device leggere/scrivere
4. dire al device di usare quel DMAC, indicandogli l'operazione da farsi
e...
5. impostare l'ISR per quando il DMAC avrà finito

...anche se il DMAC non genera l'interrupt di "operazione terminata" noi dobbiamo sapere quando la scrittura finisce e, tipicamente, a farci "il favore" è il device. Il device tipicamente ci comunica anche se c'è stato un errore da qualche parte.

Solo (e probabilmente finora non ve ne siete accorti) che il DMAC non ha un MMU e non lavora con le tabelle di pagina, a "lui" bisogna dare gli indirizzi reali di memoria... e se ne strafrega anche delle cache.
Per questo in generale l'area interessata dai trasferimenti DMA è "non cacheable" (o, al massimo, write through) e prima d'iniziare un DMA transfer tocca fare un cache flush (scaricare tutti i contenuti delle cache in memoria).

Per questo anche la soluzione dei DMAC (seppur ancora usata in alcuni ambiti particolari) è stata abbandonata e sostituita da un sistema più pratico, che è quello dei dispositivi "bus master".

Prima di riprendere in mano il "problema" dell'assenza di MMU dei DMA transfer che è un problema abbastanza particolare, spieghiamo brevemente come funzionano i sistemi busmaster.
In pratica il concetto centrale di un sistema bus master è il bus... esattamente come per le cache.
Al bus sono connessi vari dispositivi (in quest'ottica anche la RAM ed i core sono dispositivi) ed ogni dispositivo può, secondo una logica d'arbitraggio propria del bus, diventare "master" (occupare il bus) ed inviare richieste di lettura/scrittura al suo "slave" (il dispositivo "bersaglio").
Questo ci libera dal problema di avere un numero finito di DMAC e doverli condividere/programmare... lavorando in bus master ogni dispositivo che ne ha bisogno può effettuare le operazioni che gli occorrono direttamente, al più l'OS deve programmare il dispositivo, ma una volta impostato quest'ultimo "lavora" indipendentemente.
Il bus master permette, ad esempio, che una VGA possa leggere/scrivere dati dalla RAM di sistema qualora ne abbia bisogno senza "disturbare" il resto del sistema... permette di programmare trasferimenti multipli da/per il disco e, non meno importante, permette di gestire in modo semplice ambienti NUMA.

Di NUMA (Non Uniform Memory Access) abbiamo già parlato velocemente... in pratica tutti i sistemi che circolano oggigiorno sono NUMA.
Nel dettaglio UMA (Uniform Memory Access) è quando la memoria è essenzialmente un "entità" monolitica, unica e con un unico percorso/tempo d'accesso mentre NUMA è quando esistono più memorie distinte.
Per farla facile:



A sinistra alcune NUMA (memorie "divise" con "percorsi diversi") ed a destra l'UMA.
La memoria può tranquillamente rimanere unica dal punto di vista dell'indirizzamento ma a seconda degli indirizzi il percorso per accedervi può essere diverso.
E questo è proprio quello che succede oggi sui sistemi iQualcosa e da un po'sugli Athlon 64MP... in pratica ogni CPU ha il suo "banco" di memoria (cioè la memoria a cui è connesso "localmente") e la coerenza è mantenuta attraverso il bus d'interconnessione.

Và da sé che (prendiamo l'esempio in basso a sinistra) quando la CPU0 accede alla RAM sul banco 3 occupa due canali di comunicazione e subisce una penalità per la latenza (anche per questo i sistemi operativi pensati per NUMA hanno uno scheduler che cerca sempre di far girare i processi sui processori "vicini" all'immagine di memoria)... e và da sé che un DMAC che dovesse lavorare in quest'inferno d'interconnessioni diventerebbe complicato quasi quanto un piccolo processore.

La cosa è diversa sui "vecchi" processori Intel Core dove la memoria è, in pratica, attaccata al northbridge e tutte le CPU "passano" di là, quella è un architettura UMA.



Per questa ragione il bus mastering è così pratico... perché una volta ottenuto lo stato di "master" del bus i dati vengono inviati/ricevuti (in modo non diverso da come circolano le informazioni necessarie per l'accesso ai dati ed il controllo della coerenza delle cache) dall'interfaccia "più prossima" al device busmaster.

Notate, nell'immagine sopra ma anche qui:



...che esiste un IOH o un bus PCIe, questo perché i device su bus PCIe (o PCI, o vattelappesca) non hanno (e non devono avere) conoscenza di come funziona il sistema d'interconnessione fra le RAM, tali device si limitano a "chiedere" il mastering (o "ricevere" lo status di "slave") e comunicare attraverso il loro bus "locale" (PCIe, PCI, DC, PSI, MSI...), è il chipset (IOH o il northbridge) a "mettere in comunicazione" il device con la memoria (o con un "relay" dov'è la memoria).

Anziché dover usare un DMAC tramite bus mastering è possibile realizzare trasferimenti in modo semplice e pratico inserendo un "ponte" fra il bus d'interconnessione fra "CPU-RAM" ed il bus in cui stanno i device.
E'un bel risparmio, sia come complessità del sistema che come programmazione da parte del SO...

Visto che detto così è poco chiaro facciamo un esempio più semplice che chiarisca le cose... prendiamo ad esempio le tecnologie TurboCache/HyperMemory.
Queste due tecnologie si basano sul concetto di usare la RAM di sistema come (parte della) memoria video (VRAM), questo significa che la VGA può, in qualsiasi momento, dover leggere e/o scrivere una locazione di memoria qualsiasi nella RAM "assegnatale" dal sistema... come se fosse memoria "sua".

Per ovvie considerazioni sui tempi non avrebbe senso chiedere, via interrupt, alla CPU di effettuare la lettura, e visto che non è possibile sapere a priori cosa o quando la VGA dovrà accedere non ha senso neppure usare un DMAC... e qui il busmaster risulta decisivo.
Semplicemente quando la VGA ha bisogno di accedere alla RAM "prende il controllo" del bus ed invia i comandi di lettura/scrittura di cui ha bisogno al bus.
"Dall'altro capo" del bus a cui è collegata la VGA (PCI/AGP/PCIe) è a sua volta collegato un bridge che "recupera" quei comandi e li "instrada" verso la memoria.

In caso di un sistema NUMA (tipo un PC con due Opteron, in cui ogni Opteron ha la sua memoria "locale") le richieste vengono instradate sul bus d'interconnessione, in questo modo non solo è possibile accedere alle memorie locali in modo "trasparente" ma è possibile anche mantenere la "coerenza" della memoria in quanto anche le cache "ascoltano" sul bus d'interconnessione.

tl;dr wall of text ecc..

no dai interesting

*