This succeeds, and brings our system commit down to a mere 1GB. Let's say you fire up "HugeMemoryHogApp.exe", which at start up tries to allocate 3GB of virtual memory and touches/uses/commits it all. Note also that there are other memory usages that don't contribute to system commit either, but they are beyond the scope of this thread. The amount of system commit available is now only 4GB. Its commit charge on the system as a whole is 2GB. Note that reservation alone does NOT contribute to commit usage, but in the case of the 2GB page file (because the page file is always completely allocated), the RAM disk is definitely using (committed) all of that memory it asked for/reserved. Windows has said "yes, I will reserve this memory for you for some time in the future". The RAM disk driver has reserved 2GB of virtual memory. The 2GB paging file is now on a RAM disk which is 2GB in size. Let's pretend we have all of that available commit (impossible in the real world, but this makes it simple for the explanation). Already, we can't put the paging file into a RAM disk! There isn't enough RAM! Okay, so lets make our system a little more modern with a 64-bit OS, we'll give it 4GB of RAM with a 2GB paging file. Now what happens if we move the page file to a RAM disk? Lets stick with our crappy system of 1GB of RAM and a 2GB paging file (min/max).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |