Sull'architettura x86, perché ci sono meno bit per lo spazio di indirizzi virtuali rispetto a quelli fisici?


11

Stavo leggendo questo articolo sull'elaborazione a 64 bit e menziona:

Ad esempio, l'architettura AMD64 dal 2011 ha consentito 52 bit per la memoria fisica e 48 bit per la memoria virtuale

Penserei che avrebbe più senso consentire più memoria virtuale rispetto alla memoria fisica, quindi perché è effettivamente il contrario?

Domanda bonus: cosa significa "consentire" per 52 o 48 bit su un'architettura a 64 bit? A cosa servono gli altri bit?


Per x86, i bit VA inutilizzati devono essere un'estensione di segno dell'MSbit del VA. (ARM AArch64 offre la possibilità di consentire a 8 MSbit di essere ignorato dall'hardware in modo che possano essere convenientemente utilizzati per i tag. Il processore Azul Systems Vega - parte di un'appliance Java - ha fornito 16 bit di VA da utilizzare per i tag.) Nella tabella delle pagine, i bit PA riservati devono essere zero (principalmente per garantire che il software non tenti di usarli e rompano la compatibilità con l'hardware successivo).
Paul A. Clayton,

Risposte:


11

Ecco un'immagine di una tabella di pagine AMD64 (dalla Guida del programmatore di architettura AMD, Vol. 2, Rev 3.23, 2013, pagina 132).

Tabella delle pagine AMD64 Longmode

La dimensione "naturale" di una pagina nell'architettura AMD64 è 2 12 = 4096 byte. (Ci sono modalità in cui puoi avere 2 21 = 2 pagine di MB, ma per ora le ignoreremo.)

Ogni P-Table Page (PTE) (o, a seconda del livello chiamato PDE, PDPE o PML4E) è 64 bit = 2 3 byte. Quindi ci sono 2 9 voci per pagina. Quindi 4 livelli di tabella delle pagine ti danno 4x9 + 12 = 48 bit di indirizzo virtuale per processo. Camminare sulla tabella delle pagine è costoso, quindi non si espandono a 5 o 6 livelli a meno che / fino a quando non vi è una domanda dei consumatori.

Non sono sicuro del motivo per cui abbiano deciso un limite di indirizzo fisico a 52 bit. Questo può essere esteso fino a 63 bit in futuro. Ai prezzi di ottobre 2013 (circa 1US $ / Gigabit per chip da 4Gbit) costerebbe oltre 32.000.000,00 US $ per costruire una memoria da 2 52 byte, quindi ci vorrà un po 'prima che ci sia una richiesta significativa per aumentare il limite di indirizzi fisici. Esistono molte ragioni per cui vuoi mantenere gli indirizzi fisici il più piccolo possibile: i tag TLB e cache devono contenere indirizzi fisici, ad esempio.

Non è necessariamente all'indietro che ci sia più memoria fisica che virtuale. La memoria virtuale è per processo mentre la memoria fisica è condivisa da tutti i processi. Quindi un server con indirizzi virtuali a 48 bit e 2 52 byte di memoria potrebbe supportare 16 processi simultanei e garantire comunque di non dover scambiare.


Vale la pena notare che gli architetti informatici hanno imparato a richiedere l'uso dei bit superiori da parte dell'hardware, in genere mediante l'estensione dei segni per adattarsi all'uso comune di indirizzi negativi per il sistema operativo ("A cosa servono gli altri bit?"). Inoltre, con la memorizzazione nella cache delle voci della directory Ln, una tabella a 5 livelli non deve essere percorsa per la maggior parte del tempo. I bit PTE 52:62 sono riservati al software, quindi non possono essere utilizzati per indirizzi fisici senza interrompere la compatibilità, limitando le pagine 4KiB a 52 bit di PA. Inoltre, Linus Torvalds infuria notoriamente contro PAE (VA> PA sembra semplificare il design "tradizionale" del sistema operativo).
Paul A. Clayton,

"Questo può essere esteso fino a 63 bit in futuro." Bene, no, non senza cambiare la struttura della tabella delle pagine. Allo stato attuale, i bit da 52 a 62 del PxE sono riservati per l'uso del sistema operativo. E i sistemi operativi li utilizzano (Windows utilizza quel campo per un "indice dell'elenco di set di lavoro"), quindi gli architetti dei processori non sono liberi di espandere il campo PFN in essi. Ovviamente sarebbe possibile avere in futuro un'opzione simile a PAE che cambierebbe la struttura del PT in modo da consentire più bit di PFN, ma sarebbe un cambiamento architettonico significativo.
Jamie Hanrahan,

3

Alcuni punti da considerare, la RAM fisica è costosa. Sicuramente 16 GB sono più economici ora che 4 GB erano solo pochi anni fa, ma 2 ^ 64 (16 exabyte) ridicolmente grandi.

Quindi le estensioni di AMD di x86 per x64 "hanno permesso" fino a 2 ^ 52 limitando i registri . Questo fa due cose, riduce il costo dei processori e migliora le prestazioni. Un numero maggiore di registri non utilizzati significa che c'è molto spazio vuoto che deve ancora essere preso in considerazione durante le operazioni.

E, nel caso in cui non sei un ragazzo di matematica ... La differenza tra tre dimensioni è enorme! Non sono un guru della matematica, ma in decimale a 52 bit è circa il 0,02% di 64 bit. 48 bit è il 6% di 52. (qualcuno controlla la mia matematica?)

Per quanto riguarda il motivo per cui AMD ha permesso più RAM fisica che virtuale, l'articolo afferma che è perché AMD stava pensando ai server. I server hanno bisogno di grandi quantità di RAM fisica. La RAM virtuale è troppo lenta per supportare le applicazioni server medie per centinaia o migliaia di dipendenti.

I miei pensieri: abbiamo lasciato il tempo in cui la RAM era piccola e i dischi rigidi dovevano supportare la RAM. Il prezzo in RAM è sceso a un punto in cui la persona media può mettere più che sufficiente RAM. Prendi applicazioni tipiche, come Office che richiede 1-2 GB di RAM. Il mio computer 7 anni fa poteva gestirlo. Sebbene con velocità di lettura e scrittura su disco, spero di non dover mai recuperare un file da 7 GB dalla memoria virtuale (usando la vecchia filosofia PM * 2.5).

Posso anche supporre che AMD volesse lasciare spazio ai registri che utilizzano i registri RAM fisici, come la RAM su GPU integrate.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.