La dimensione della pagina di memoria predefinita del kernel Linux su architettura x86 era di 4 KB, mi chiedo come è stato calcolato e perché?Perché la dimensione della pagina di Linux (x86) 4 KB, come viene calcolata?
La dimensione della pagina predefinita viene fissata da ciò che l'MMU (unità di gestione della memoria) della CPU supporta. In 32-bit x86 modalità protetta supporta due tipi di pagine:
Non tutti i processori x86 supportare grandi pagine. Uno ha bisogno di avere una CPU con capacità di estensione della pagina (PSE). Ciò esclude i processori pre-Pentium. Praticamente tutte le CPU x86 di generazione corrente lo implementano.
4 KiB è ampiamente granularità di pagina popuplar anche in altre architetture. Si potrebbe sostenere che questa dimensione proviene dalla divisione di un indirizzo virutale a 32 bit in due indici a 10 bit nelle directory/tabelle di pagine e i 12 bit rimanenti danno la dimensione della pagina di 4 KiB.
ho ottenuto questo dalla voce di Wikipedia e cito:
dimensione della pagina è di solito determinata da architettura del processore
Partenza l'articolo qui sotto:
That depends on the processor architecture.
La dimensione della pagina predefinita è 4 KB su molte architetture. Generalmente può essere aumentato (a volte molto, come 1 GB di AMD64) passando alla modalità huge page. Ciò consente alla tabella di pagine di essere più piccola, il che può comportare miglioramenti delle prestazioni.
La progettazione di 4 KB normale dimensione della pagina di architettura a 32 bit è in realtà molto interessante :)
e vorrei aggiungere una risposta in più per dimostrare il motivo per cui è ragionevole.
x86 utilizza '2-pass' per tradurre gli indirizzi di memoria virtuale in indirizzi di memoria fisica.
Supponiamo quindi che sia la directory di pagina sia la tabella di pagina contengano le voci 
e che la dimensione della pagina sia 
byte. Per sfruttare appieno l'indirizzo 
, abbiamo:
Ogni voce nella directory page/tavolo consuma 4 byte (32 bit), quindi:
Così y = 12 e la dimensione della pagina in byte sarà = 
= 4KB.
E che dire di "1-pass"? Questo è interessante perché logicamente possiamo usare una tabella a pagina singola per la ricerca degli indirizzi.
Si supponga che la directory della pagina contenga le voci 
, ciascuna che associa un indirizzo alla pagina corrispondente e la dimensione della pagina è 
byte.
Ancora una volta, a fare pieno uso delle indirizzi, abbiamo bisogno di:
E:
otteniamo y = 17, e le dimensioni della pagina è = 
= 128 KB.
In ogni caso, questo funziona "logicamente". Se introduciamo TLB, una dimensione così grande della memoria sarà un diaster: le pagine di memoria saranno difficili da adattare a TLB e il design non sarà efficiente.
Potremmo anche sostenere che, nella versione '2-pass', la directory di pagina e tabella delle pagine potrebbe avere dimensioni diverse. Tuttavia, questo significa che utilizzeremo una directory di pagine più grande, che occuperà più di una pagina di memoria. Purtroppo, ogni volta che viene generato un nuovo processo utente, per la propria directory di pagina, il sistema operativo deve allocare pagine successive, che non sono eleganti per design.
La terminologia normale è "tabella pagine di 2 livelli", non "2 passaggi". per esempio. [x86-64 utilizza una tabella di pagina a 4 livelli] (https://stackoverflow.com/questions/46509152/why-in-64bit-the-virtual-adress-are-4-bits-short-48bit-long-compared -with-the) (sempre con 4k pagine normali, ma le pagine enormi sono 2M o 1G invece di 4M.) –
La sezione della tabella di pagina a 1 livello fa un'assunzione non necessaria: la tabella di pagina stessa non * ha * 1 pagina in dimensione. Potresti avere pagine più piccole (e una tabella di pagina piatta ancora più gigantesca).Quello che fa schifo a livello 1 è la dimensione della tabella di pagina: un processo con solo una piccola quantità di memoria mappata può avere un albero sparse con solo un paio di tabelle di pagina di livello inferiore. TLB non è affatto un problema; ogni TLB contiene la traduzione completa da tutti i livelli della tabella della pagina, quindi le pagine più grandi significano meno bit di pagina, ovvero una CAM più piccola. E un minor numero di voci TLB copre più memoria. –
Aggiungo questa risposta/commento perché il calcolo di sleepsort è molto interessante, devo aggiungerlo alla mia pagina web (con menzione della fonte ovviamente). Una (possibile) risposta alla domanda su come è possibile calcolare la pagina a livello di codice può essere trovata here. Il modo in cui viene calcolato come menzionato da sleepsort è molto interessante. Ho fatto lo stesso per x86_64 e il risultato non era quello che mi aspettavo. Comunque ulteriori letture su memory management x86_64 ho scoperto che per l'intel a 64 bit, 16 bit non sono usati, lasciandolo a 48 bit da calcolare. 9 bit per i rami dell'albero della memoria, ogni ramo altri 9 bit, qui in un altro 9 per le filiali e infine 9 bit per le foglie dell'ultimo ramo. Quindi 48 - 36 = 12 bit per ogni indirizzo nella pagina di memoria. 2^12 = 4096 come accennato prima da sleepsort. Mi chiedo quanti passaggio questa architettura è, 3 o 4 (se qualcuno può spiegare che) seguente calcolo di sleepsort:
2^x * 2^x * 2^x * 2^x * 2^y = 2^48
4x + y = 48
this time we have 8 bytes for each address (8 bytes * 8 bits/byte = 64 bits)
2^y/2^3 = 2^x
y - 3 = x
filled in in previous equation:
4(y - 3) + y = 48
4y - 12 + y = 48
5y = 60
y = 12
because 2^y represents the pagesize, the size = 2^12 = 4096 bytes
mi lascio con la domanda: "che dire di quelle enormi pagine in Linux"?
Le pagine giganti 4M sono solo per la modalità x86 a 32 bit. 64-bit x86 utilizza pagine enormi 2M o 1G, perché il formato di tabella di pagina a 4 livelli utilizza 9 bit per livello. https://stackoverflow.com/questions/46509152/why-in-64bit-the-virtual-address-are-4-bits-short-48bit-long-compared-with-the. (La dimensione non enorme della pagina è ancora 4k in modalità lunga, quindi la cache L1DTLB e L1D può ancora funzionare sostanzialmente allo stesso modo, tra le altre ragioni.) –
@PeterCordes, grazie per il tuo commento. Ho effettivamente indirizzato solo la modalità a 32 bit e questo è quello che di solito denoto con x86. –