[sistemi operativi] paginazione

[nuovoUtente86]

Se ne discuteva nell' area di Vista ma nin si è giunti a nessuna conclusione!
In sostanza un sistema a 32 bit senza alcuna estensione PAE abilitata puo indirizzare, per limite numerico dei 32 bit, 4GB totali di memoria.Tale memoria deve essere data dalla somma della ram e dal file di swap?
Stranamente il mio Vista Premium con 2GB di ram...invece di 4096 arriva a 4300MB

[gugoXX]

4GB e' il limite del solo indirizzamento fisico.
L'indirizzamento virtuale e' molto piu' esteso.
E' limitato sotto windows a seconda della versione, ma gia' sul 386 poteva raggiungere 64TeraByte.

library.nocrew.org/lib/cpu/23163011.pdf
Datasheet del 386, primissima pagina, da apporfondire sul capitolo della segmentazione.

[nuovoUtente86]

Ora leggo il documento.
Ma quando su diversi documenti(anche microsoft) inerenti l' argomento si trova scritto che per le architetture la memoria virtuale massima è di 4GB..a cosa si riferiscono?forse al singolo processo?

La cosa che non capisco è come superare tale limitazione di spazio utilizzando solo i 32 bit.

Credo poi, ma non ne sono sicuro, che i sistemi atuali utilizzino un misto di paginazione esegmentazione.

[gugoXX]

Originariamente inviato da nuovoUtente86

Ora leggo il documento.
Ma quando su diversi documenti(anche microsoft) inerenti l' argomento si trova scritto che per le architetture la memoria virtuale massima è di 4GB..a cosa si riferiscono?forse al singolo processo?

Esatto.
Lo spazio di memoria virtuale dedicabile per ciascun processo sotto l'architettura x86 a 32bit e' di 4GB.
Windows ha dedicato storicamente 2GB di questi per i dati e il codice, mentre altri 2GB erano dedicati al kernel.
Con il paramentro /3G e' possibile dedicare fino a 3GB per dati e codice, e uno solo per il kernel.

Processo non significa comunque applicazione. Ci sono applicazioni multiprocesso (ES: SQL Server) che potendo avere piu' di un processo, possono venirsi dedicati "virtualmente" piu' di 4GB.

La cosa che non capisco è come superare tale limitazione di spazio utilizzando solo i 32 bit.

Credo poi, ma non ne sono sicuro, che i sistemi atuali utilizzino un misto di paginazione esegmentazione.

Un processore (ad un solo core) esegue un solo task alla volta. Tale task ha una visibilita' di 4GB virtuali. Se ci fosse solo lui lo schedulatore della paginazione potrebbe dedicargli tutta la memoria fisica disponibile. E' un discorso al limite ovviamente, perche' capitera' sempre che ci siano altri processi fondamentali che non usciranno mai dalla memoria fisica (come il paginatore stesso, la system cache, etc.)

I sistemi di oggi, ma gia' anche da NT, usano segmentazione+paginazione.
La paginazione e' proprio il supporto hardware per il file di scambio, mentre la segmentazione e' il principalmente usata per i meccanismi di protezione ad anelli, che sembrano semplici, ma non lo sono (o almeno per me la call-gate mi fregava sempre)
Tali meccanismi sono stati accennati dal 286, realizzati con il 386 e praticamente sono rimasti invariati fino al Pentium4, a parte una breve attimo di euforia quando il PenitumPro ha esteso i pin di indirizzi da 32 a 36, con conseguente aumento dell'indirizzamento fisico possibile da 4GB a 64GB.

Comunque per fortuna sta morendo tutto, con i 64bit e' tutto piu' semplice. Il modello di memoria e' quello flat, senza registri di segmento o selettori.
Non so neppure se ci sia un qualche tipo di segmentazione, ma spero che non l'abbiano messo.

[cdimauro]

In realtà anche con l'architettura AMD64 la segmentazione è rimasta, in particolare si usano i registri FS e GS per accedere ad aree di memoria di sistema.

Tolto questo, mi sembra che non ve ne sia rimasta più traccia, per cui "di fatto" possiamo considerarla scomparsa.

[nuovoUtente86]

Originariamente inviato da gugoXX

Esatto.
Lo spazio di memoria virtuale dedicabile per ciascun processo sotto l'architettura x86 a 32bit e' di 4GB.
Windows ha dedicato storicamente 2GB di questi per i dati e il codice, mentre altri 2GB erano dedicati al kernel.
Con il paramentro /3G e' possibile dedicare fino a 3GB per dati e codice, e uno solo per il kernel.

Processo non significa comunque applicazione. Ci sono applicazioni multiprocesso (ES: SQL Server) che potendo avere piu' di un processo, possono venirsi dedicati "virtualmente" piu' di 4GB.




Un processore (ad un solo core) esegue un solo task alla volta. Tale task ha una visibilita' di 4GB virtuali. Se ci fosse solo lui lo schedulatore della paginazione potrebbe dedicargli tutta la memoria fisica disponibile. E' un discorso al limite ovviamente, perche' capitera' sempre che ci siano altri processi fondamentali che non usciranno mai dalla memoria fisica (come il paginatore stesso, la system cache, etc.)

I sistemi di oggi, ma gia' anche da NT, usano segmentazione+paginazione.
La paginazione e' proprio il supporto hardware per il file di scambio, mentre la segmentazione e' il principalmente usata per i meccanismi di protezione ad anelli, che sembrano semplici, ma non lo sono (o almeno per me la call-gate mi fregava sempre)
Tali meccanismi sono stati accennati dal 286, realizzati con il 386 e praticamente sono rimasti invariati fino al Pentium4, a parte una breve attimo di euforia quando il PenitumPro ha esteso i pin di indirizzi da 32 a 36, con conseguente aumento dell'indirizzamento fisico possibile da 4GB a 64GB.

Comunque per fortuna sta morendo tutto, con i 64bit e' tutto piu' semplice. Il modello di memoria e' quello flat, senza registri di segmento o selettori.
Non so neppure se ci sia un qualche tipo di segmentazione, ma spero che non l'abbiano messo.

Molto chiaro.
Tirando le somme:
ogni processo ha uno spazio virtuale di indirizzamento di 4GB(avevo letto da qualche parte che su XP fosse stato ridotto a 2, ma probabilmente si riferiva alla sola area codice-dati) divisi equamente tra dati-codice e spazio riservato al sistema. Quindi ogni processo ha gli indirizzi virtuali da 0 a (2^32)-1.
Ora se ricordo bene per la risoluzione degli indirizzi da virtuali a fisici si utilizzano delle gerarchie di tabelle accedute utilizzando porzioni dell' indirizzo virtuale a 32 bit, ma per consentire ad ogni processo di avere 4GB virtuali con soli 32bit disponibili vuol dire che ogni processo ha associato una struttura propria in grado di mappare l' indirizzo...o c' è qualcosa che mi sfugge?!

[gugoXX]

Guarda, e' molto lunga la faccenda, se proprio sei interessato e non si fa avanti nessuno posso provare a spiegare quello che mi ricordo.
E' comunque tutto scritto sul datasheet del 386.
Basta che cerchi il capitolo sulla composizione dell'indirizzo fisico.
Cerca concetti come la GDT, la LDT e i selettori.
Come detto, non e' proprio tutto semplice. Meno male che se ne sono liberati.

[cdimauro]

Originariamente inviato da nuovoUtente86

Ora se ricordo bene per la risoluzione degli indirizzi da virtuali a fisici si utilizzano delle gerarchie di tabelle accedute utilizzando porzioni dell' indirizzo virtuale a 32 bit, ma per consentire ad ogni processo di avere 4GB virtuali con soli 32bit disponibili vuol dire che ogni processo ha associato una struttura propria in grado di mappare l' indirizzo...o c' è qualcosa che mi sfugge?!

E' esatto. La struttura di cui parli è la page table, e normalmente è a 2 livelli.

La traslazione da indirizzo virtuale (a 32 bit) a indirizzo fisico avviene nel seguente modo:
- si prendono i 10 bit più alti, e si seleziona la entry (ce ne sono 1024) nella "master" page table (di cui ogni processo ha ovviamente un registro che ne contiene il puntatore) da cui si prelevano il puntatore alla page table di secondo livello e relativi flag (che si usano per marcare la pagina opportunamente; es.: pagina utente o supervisore, pagina eseguibile, pagina non presente, ecc.).
- si prendono i seguenti 10 bit, e si seleziona la entry nella page table di secondo livello da cui si preleva (finalmente) il puntatore alla pagina di memoria a cui accedere e relativi flag;
- si prendono i rimanenti 12 bit (i meno significativi) e si sommano (per la precisione: si copiano così come sono) al puntatore di cui al precedente punto, e si prelevano anche i flag.

A questo punto si ha finalmente il puntatore alla memoria fisica a cui accedere.

Questo a grandi linee, senza considerare cache TLB e segmentazione (qui ho illustrato soltanto la paginazione).

[nuovoUtente86]

Originariamente inviato da cdimauro

E' esatto. La struttura di cui parli è la page table, e normalmente è a 2 livelli.

La traslazione da indirizzo virtuale (a 32 bit) a indirizzo fisico avviene nel seguente modo:
- si prendono i 10 bit più alti, e si seleziona la entry (ce ne sono 1024) nella "master" page table (di cui ogni processo ha ovviamente un registro che ne contiene il puntatore) da cui si prelevano il puntatore alla page table di secondo livello e relativi flag (che si usano per marcare la pagina opportunamente; es.: pagina utente o supervisore, pagina eseguibile, pagina non presente, ecc.).
- si prendono i seguenti 10 bit, e si seleziona la entry nella page table di secondo livello da cui si preleva (finalmente) il puntatore alla pagina di memoria a cui accedere e relativi flag;
- si prendono i rimanenti 12 bit (i meno significativi) e si sommano (per la precisione: si copiano così come sono) al puntatore di cui al precedente punto, e si prelevano anche i flag.

A questo punto si ha finalmente il puntatore alla memoria fisica a cui accedere.

Questo a grandi linee, senza considerare cache TLB e segmentazione (qui ho illustrato soltanto la paginazione).

Molto esauriente....praticamente da manuale....Questo avviene in maniera lineare se la pagina è in ram, in caso contrario dopo il page fault il sistama deve caricare la pagina mancante..presumo..

di cui ogni processo ha ovviamente un registro che ne contiene il puntatore

puntatore alla page table privata di ogni processo?

[khelidan1980]

Originariamente inviato da cdimauro

E' esatto. La struttura di cui parli è la page table, e normalmente è a 2 livelli.

La traslazione da indirizzo virtuale (a 32 bit) a indirizzo fisico avviene nel seguente modo:
- si prendono i 10 bit più alti, e si seleziona la entry (ce ne sono 1024) nella "master" page table (di cui ogni processo ha ovviamente un registro che ne contiene il puntatore) da cui si prelevano il puntatore alla page table di secondo livello e relativi flag (che si usano per marcare la pagina opportunamente; es.: pagina utente o supervisore, pagina eseguibile, pagina non presente, ecc.).
- si prendono i seguenti 10 bit, e si seleziona la entry nella page table di secondo livello da cui si preleva (finalmente) il puntatore alla pagina di memoria a cui accedere e relativi flag;
- si prendono i rimanenti 12 bit (i meno significativi) e si sommano (per la precisione: si copiano così come sono) al puntatore di cui al precedente punto, e si prelevano anche i flag.

A questo punto si ha finalmente il puntatore alla memoria fisica a cui accedere.

Questo a grandi linee, senza considerare cache TLB e segmentazione (qui ho illustrato soltanto la paginazione).

ma solo io ho la memoria a breve termine??Questa roba lo resettata pochi mesi dopo aver datto l'esame di sis op....

[nuovoUtente86]

Originariamente inviato da khelidan1980

ma solo io ho la memoria a breve termine??Questa roba lo resettata pochi mesi dopo aver datto l'esame di sis op....

anche io l' ho resettata...ma come vedi poi tutto torna utile...Grazie al forum e a qualche dispense mi sono rinfrescato la memoria..anche perchè...durante i corsi molti particolari vengono trascurati per questioni di tempo.

[cdimauro]

Originariamente inviato da nuovoUtente86

Molto esauriente....praticamente da manuale....Questo avviene in maniera lineare se la pagina è in ram, in caso contrario dopo il page fault il sistama deve caricare la pagina mancante..presumo..

Presumi benissimo, ma un page fault non deve necessariamente "caricare" la pagina mancante: è sufficiente che ne fornisca una che non scateni nuovamente il page fault.

puntatore alla page table privata di ogni processo?

Sì. Se non ricordo male è uno dei registri CRx (con x da 1 a 7; non può essere il CR0 perché è il registro di "stato" più importante), ma al momento non ricordo di preciso quale.

Originariamente inviato da khelidan1980

ma solo io ho la memoria a breve termine??Questa roba lo resettata pochi mesi dopo aver datto l'esame di sis op....

E fai benissimo: ormai programmare in assembly è una perdita di tempo, per cui molto meglio farne a meno.

Io ricordo ancora oggi alcuni dettagli (non tutti, come puoi vedere sopra), semplicemente perché ho lavorato in assembly per parecchi anni, e ai tempi dell'Amiga avevo quasi finito un buon emulatore 80186, da far evolvere poi in 286 prima e 386 poi, per cui non mi sono limitato a studiarmi l'assembly di questi processori, ma anche (dettagliatamente) l'ISA.

[gugoXX]

E poi da bravo furbacchione mica ti sei messo a partire con lo spiegare l'unita' di segmentazione ...

[cdimauro]

Se posso evitare, è meglio.

Comunque ho sempre sostenuto la paginazione e non la segmentazione (peggio ancora la combinazione delle due), ma devo riconoscere che per alcuni problemi (piuttosto comuni) la segmentazione fornisce una soluzione semplice, veloce ed elegante.

[nuovoUtente86]

Originariamente inviato da cdimauro

Presumi benissimo, ma un page fault non deve necessariamente "caricare" la pagina mancante: è sufficiente che ne fornisca una che non scateni nuovamente il page fault.

Ma se un processo necessità di una pagina(codice o dati) e questa è swappata cosa gli si può restituire, piuttosto che caricare la pagina cercata
?

[gugoXX]

Originariamente inviato da nuovoUtente86

Ma se un processo necessità di una pagina(codice o dati) e questa è swappata cosa gli si può restituire, piuttosto che caricare la pagina cercata
?

Stava parlando (forse) dell'allocazione, ovvero quando fai richiesta al SO di un tot di memoria a tuo uso e consumo.

[cdimauro]

Originariamente inviato da nuovoUtente86

Ma se un processo necessità di una pagina(codice o dati) e questa è swappata cosa gli si può restituire, piuttosto che caricare la pagina cercata
?

Se una pagina è stata "swappata", è chiaro che dovrà essere ricaricata.

Ma, come dicevo, un page fault non necessariamente deve produrre il caricamento di una pagina. Dipende tutto da quello che vuoi implementare.

Originariamente inviato da gugoXX

Stava parlando (forse) dell'allocazione, ovvero quando fai richiesta al SO di un tot di memoria a tuo uso e consumo.

Generalmente è così, infatti, ma le possibilità offerte dai page fault vanno ben oltre (e si allargano ancora in combinazione con la logica di "resume" da un fault).

P.S. Si capisce che non ne voglio parlare in dettaglio?

[nuovoUtente86]

Originariamente inviato da gugoXX

Stava parlando (forse) dell'allocazione, ovvero quando fai richiesta al SO di un tot di memoria a tuo uso e consumo.

solitamente(almeno in windows) mi sembra il sistema mantenga in ram delle pagine libere....Ma a parte questo(potrei certamente sbagliare) la butto li: può essere allocata una pagina riutilizzabaile...(dovrebbero chiamarsi azzerate o qualcosa del genere).


Dal discorso mi pare di capire che lavorando in assembly è possibile avere una maggiore interezione e controllo della paginazione che con la programmazione ad alto livello è del tutto trasparente essendo di fatto ad opera del SO!E' cosi?

[gugoXX]

Anche con l'assembly, a livello utente, e' tutto nascosto e gestito dal sistema operativo.
L'unica cosa che puoi fare (ma lo fai anche ad alto livello) e' chiedere della memoria, lui te la da, e tu la usi, senza porti particolari problemi se non quello di rilasciarla correttamente quando hai finito di usarla.
Inoltre per come sono fatti Windows e Linux per l'interazione con il SO e' meglio il C++ che l'assembly
Forse anche il C va bene, ma gia' sotto Windows3.11 si usava il C++, non so quanti abbiano usato il C puro per interfacciarsi con Windows.

Questo a meno che tu non stia programmando dei driver, o addirittura un sistema operativo stesso, nel qual caso e' praticamente certo che tu debba sporcarti le mani con l'assembly in alcune parti critiche (come queste della segmentazione e della paginazione). Per il resto era gia stato studiato in modo che per gli sviluppatori fosse tutto trasparente