(Note: This is a simplified explanation).īecause the point of this thread is to not explain how virtual memory works, but rather why you shouldn't place your page file on a RAM disk, I will only quickly iterate some underpinnings about virtual memory: When a program allocates or uses virtual memory from its address space, the Windows memory manager maintains a look up table (and the CPU copies it with what is called the translation look-aside buffer, or TLB) of virtual addresses to physical addresses in RAM. For 64-bit Windows the default address space for user-mode applications is 8TB and the kernel has 8TB also. The Windows kernel itself fits into the remaining 2GB. This virtual memory abstraction is in place because it means we don't actually have to worry about how much physical memory is installed on the system (you'll see how the page file comes into play with this shortly).įor 32-bit Windows the default address space for user-mode applications is 2GB. This essentially gives each process (including paged-pool drivers) on your system their own virtual address space in which to play in. The Windows memory manager works closely with the CPU to provide what is called "virtual memory". You need to know that programs do not directly access your physical memory sticks. The first thing we need to understand when explaining this issue is how Windows manages memory. I think this topic could have the potential to spark much debate, but I am going to have a vain attempt at explaining why it is actually counter intuitive to place your page file on a RAM disk, or other virtual storage device that creates a backing store using RAM. I've seen this recommendation time and time again and I for one do not care for it really.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |