Infatti si potrebbe approfondire - in modo del tutto accademico - il modo in cui Windows determina la quantità di memoria virtuale necessaria... (@BAT ? ) saranno algoritmi non troppo complicati visto che comunque la gestione della memoria è inclusa (e penso sia ancora basata sugli stessi principi) della prima versione di Windows... almeno credo.
Di quello non ho mai parlato nemmeno nei miei precedenti articoli, mi sono limitato alla traduzione degli indirizzi virtuali in indirizzi fisici (
Memoria Virtuale: x64 Virtual Address Translation)... considera che il "memory management" (citato da BAT) è descritto in circa 200 pagine sul libro che ha linkato
Ora non so bene se è questo che intendi, ma la memoria necessaria in realtà aumenta quando il processo stesso viene caricato in memoria. La parte caricata è infatti ridotta ed è il working set. Quando un thread lancia un eccezione (page fault) il memory manager si occupa di caricare dal disco la pagina che ha lanciato quell'eccezione e metterla in memoria; assieme a questa pagina ne carica alcune altre adiacenti, poichè "presume" che potrebbe avvenire un accesso anche a quelle.
In realtà il caricamento avviene a cluster, così da non dover leggere effettivamente ogni volta sul disco.
C'è poi un componente (più di uno in realtà) che si occupa di ottimizzare il primo avvio di un programma o del sistema stesso, chiamato "logical prefetcher" . Ne parla (più o meno... molto meno che più) Wiki
https://en.wikipedia.org/wiki/Prefetcher
Un altro è "SuperFetch", ma noto che in rete non ci sono info in merito.
La memoria virtuale che viene poi messa sul disco viene "scelta" tramite delle policy; uno di quelli usati se non vado errato è la "clock policy", si chiama clock algorithm (
LRU - Wikipedia). Il discorso poi è complicato, ricordo che fa uso di più policy (locali e globali).
Come viene determinata la quantità di memoria?
Ora, la domanda che ti poni mi sembra sia "come viene determinato per processo?". Ogni processo ha un working set di default che varia da 50 a 350 pagine (circa, probabilmente sto arrotondando xD). In buona sostanza, se non vado errato il limite massimo non è presente, a patto che ci siano ancora pagine disponibili; il liimte è di fatto la memoria fisica di cui disponi (questo perchè l'upper range è qualcosa come 128TB, la quantità di memoria virtuale, il che è impossibile da raggiungere ora come ora).
Se non erro si possono cambiare e specificare limiti, ma dovevano essere apportate modifiche impostando tipo uno scheduling priority differente.
Che succede dopo un page fault? Come dicevo sopra viene portata in memoria la pagina, facendo crescere la memoria; ciò però non avviene quando la memoria disponibile è ridotta, in tal caso vengono rimosse pagine dal working set.
Il discorso è molto complesso, ci sono anche algoritmi di compressione per comprimere le pagine in modo che più pagine vengano anche compresse in una, così da liberare quelle pagine e allocarne solo 1 (si tratta di quella visibile ad esempio dal task manager sotto "Memoria compressa"). Sono tutte decisioni prese dal memory manager.
Queste considerazioni valgono soprattutto per Windows > 8. Magari prima o poi scriverò un articolo non troppo approfondito in merito, anche se avrò bisogno di un ripasso prima.
Sono stato un pò dispersivo me ne rendo conto; è un argomento complesso che merita diverso tempo, ma spero di aver almeno chiarito qualcosa, un minimo. :)
Ma il mio discorso e i miei test dimostrano che la memoria vincolata di sistema è una memoria reale utile e indispensabile al funzionamento di sistema e non è per nulla una previsione ipotetica
Non è da disabilitare infatti, proprio per tutta la serie di considerazioni sopra esposte. Le pagine non usate o meno utilizzate vengono messe in quel pagefile.sys. Quando la tua applicazione richiede memoria, e un gioco ne richiede parecchia, viene usata la RAM. Se non ne hai abbastanza - considerando che hai in esecuzione altri software - si verifica il crash.
).
