Spostare il file di paging nella RAM è una nozione ridicola Basta spegnerlo e con più RAM. :)
No matter how much RAM you have, you want the system to be able to use it efficiently. Having no paging file at all forces the operating system to use RAM inefficiently for two reasons. First, it can't make pages discardable, even if they haven't been either accessed or modified in a very long time, which forces the disk cache to be smaller. Second, it has to reserve physical RAM to back allocations that are very unlikely to ever require it (for example, a private, modifiable file mapping), leading to a case where you can have plenty of free physical RAM and yet allocations are refused to avoid overcommitting.
Consider, for example, if a program makes a writable, private memory mapping of a 4GB file. The OS has to reserve 4GB of RAM for this mapping, because the program could conceivably modify every byte and there's no place but RAM to store it. So immediately, 4GB of RAM is basically wasted (it can be used to cache clean disk pages, but that's about it).
La gestione della memoria è gestita dalla CPU e il fatto che il file di paging sia acceso o spento non fa differenza di come vengono trattate le pagine. È trasparente per Windows.
La priorità della pagina non cambia, le pagine verranno eliminate allo stesso modo. I file di paging vengono utilizzati dalla CPU come memoria secondaria, non dal sistema operativo. Non è altro che cache di livello due quando si esaurisce il livello uno (RAM).
Un esempio rapido e molto sporco: la mia macchina ha 16 GB di RAM e nessun file di paging. 5 minuti fa con 13 GB in standby e solo 2 GB gratuiti, ho caricato Fallout 4. Le pagine a bassa priorità sono state scartate quando Fallout è stato caricato.
A proposito, il Technet Blog del 2008 sulla spinta dei limiti di memoria di Windows è molto fuorviante - direi fino all'inganno.
https://i.stack.imgur.com/wXkmi.png
Sono anche dubbioso se anche Mark lo abbia scritto, ma spero di no, poiché cambierebbe la mia prospettiva su di lui .....
In seguito ci sono buchi spalancati nell'articolo di cui sono stupefatto che nessuno ha preso in considerazione considerando la frequenza con cui quel blog è stato segnalato
- Il file di paging e la sua posizione sono gestiti da Windows, il trapping dell'accesso alla memoria alle posizioni che sono state paginate su disco verrebbero catturati dalla CPU, ma consegnati al sistema operativo per recuperare la pagina dal disco e caricarla.
Comunque qui c'è una descrizione non così vaga:
Windows non può raggiungere indirizzi più alti rispetto alla CPU - non è possibile.
Indipendentemente dalle capacità del sistema operativo, è ancora limitato dall'hardware su cui è in esecuzione ... perché il sistema operativo è in realtà la CPU stessa (registri interni).
OK, quindi il file di paging è un'area sull'HDD che la CPU utilizza per lo spazio di indirizzi fisico esteso quando non è in grado di utilizzare più RAM fisicamente o architettonicamente.
Nell'architettura segmentata x86 a 32 bit, ad esempio, ci sono due segmenti da 2 GB di RAM.
Uno è assegnato al kernel. Gli altri 2 GB sono per la modalità utente. Questa è tutta la RAM che la CPU può utilizzare con 32 pin DRAM, ma un processo a 32 bit ha 4 GB disponibili, quindi cosa fare. Fortunatamente la CPU può utilizzare l'archiviazione secondaria AKA sul disco rigido per archiviare 2 GB di pagine in più. Perché ha registri interni
Le posizioni fisiche in cui le pagine virtuali a cui fa riferimento il processo non devono essere archiviate nella RAM. Ma sono stati memorizzati da qualche parte dalla CPU.
La CPU non può dare tutta la RAM da 4 GB all'app, ma può fornirle 4GB di indirizzo utilizzando l'HDD come cache secondaria (che è tutto l'HDD realmente)
Le pagine vengono spostate dentro e fuori dalla RAM attraverso il suo meccanismo di paging interno, ma questo non è lo stesso di un file di paging. Il paging si verifica sempre ....
La linea di fondo non è poi così complicata. Negli ultimi 15 anni a molti utenti finali è stata data l'impressione che un file di paging sia parte integrante del sistema operativo, non lo è. Non è mai stato. Questo malinteso è in parte alimentato da società come Intel e Microsoft.
La RAM è un dispositivo di archiviazione veloce, il disco rigido è un dispositivo di archiviazione più lento, quindi essenzialmente la RAM è cache di livello 1, il disco rigido è di livello 2 (ignorando la cache della CPU per questa analogia). Entrambi sono accessibili dalla CPU.
Se non è disponibile RAM sufficiente per la CPU per memorizzare le pagine necessarie, è possibile utilizzare l'HDD come overflow. Se c'è molta RAM, il PF è ridondante.
Fino al Core 2, i processori Intel avevano un bus DRAM a 32 pin e 32 registri che indicavano che la CPU aveva accesso a 4 GB di RAM e 4 GB di spazio su disco rigido (file di paging). Questa è una limitazione hardware dell'architettura, non una limitazione di Windows.
Il totale disponibile per i processi era di 3,5 GB, poiché una tabella di pagine occupa 512 MB. Ecco perché 3,5 GB vengono visualizzati in Windows con CPU Intel (fino al Core 2). Aggiungi una GPU e anche meno è disponibile.
Xeon potrebbe accedere a un totale di 32 GB di RAM, 64 GB di spazio fisico con HDD incluso (di nuovo file di paging). ( Questo ^ riguarda PAE, -così verranno aggiunti collegamenti ).
http://www.windowsdevcenter.com/pub/a/windows/2004/04/27/pagefile.html
Terza fonte di screenshot:
Interfaccia binaria dell'applicazione System V AMD64 Architecture Processor Supplement Draft Version 0.99.7
Intendo continuare a migliorare questa risposta e aggiungere materiale sorgente e informazioni pertinenti. Vorrei raggiungere un equilibrio tra informazioni insufficienti e troppe informazioni tecniche. I suggerimenti sono benvenuti. Per favore, non sottovalutare solo perché potrebbe non essere scritto così bene.