In modern operating systems, including Windows, application programs and many system processes always reference memory using virtual memory addresses which are automatically translated to real (RAM) addresses by the hardware.
Only core parts of the operating system kernel bypass this address translation and use real memory addresses directly.
Virtual Memory is always in use, even when the memory required by all running processes does not exceed the amount of RAM installed on the system.
Windows 32-bit Operating Systems implement a virtual memory system based on a flat 32-bit address space. 32-bits of address space translates into 4GB of virtual memory. A process can access up to 4GB of memory address space. Any process (e.g. application executable) running under 32 bit Windows versions gets a set of virtual memory addresses (a Virtual Address Space) going from 0 to 4,294,967,295 (2*32-1 = 4 GB), no matter how much RAM is actually installed on the computer. Actually, this is essentially the same for all operating systems running on 32 bit hardware that implement Virtual Memory.
In the normal, default 32 bit Windows OS configuration, 2 GB of this virtual address space are allocated to the process’ private use and the other 2 GB are allocated to shared and operating system use. Only that portion of the address space that is actually referenced (used) by a process or the system is associated with a page frame in real memory, or in the pagefile.
(Using the /3GB switch changes this behavior – read more later).
Kernel-mode Memory and User-mode Memory
First the differences in Kernel-mode and User-mode memory. The system space (aka Kernel space) is the portion of the address space in which the OS and kernel-mode drivers reside. Only kernel-mode code can access this space.
User-mode threads can access data only in the context of their own process. User-mode threads cannot access data within another processes space directly, nor can it access the system address space directly.
Kernel-mode drivers are trusted by the OS and can access both kernel and user space.
When a driver routine is called from a user thread, the thread’s data remains in the user-mode space. However, the kernel-mode driver can access the user-mode data for the thread and access the kernel-mode space.
If you look at the diagram, we can see how the 4GB memory address space is divided. Windows allocates the lower half of the 4GB address space (from 0x00000000 to 0x7FFFFFFF) to processes for their own unique private storage, and reserves the other half (from 0x80000000 to 0xFFFFFFFF) for the Operating System’s use. Virtual memory provides a view of memory that does not necessarily correspond to the physical layout of memory.
The virtual memory management component of the operating system maintains the tables used by the hardware to provide the mapping of virtual addresses into real addresses. A small amount of RAM is used by those parts of the operating system that can not be paged out (for example, the virtual memory manager) and is thus not available for assignment to virtual memory. The key point here is that Virtual Memory is always in use, even when the memory required by all running processes does not exceed the amount of RAM installed on the system.
This is usually the point in the discussion where the majority of folks start getting confused and their eyes start to glaze over. In simplistic terms, the memory manager translates the virtual memory addresses into physical addresses where the data is stored. Every page in virtual memory is listed in a page table which in turn identifies the correct physical page. The system and CPU use the information from the virtual address to find the correct page table entry for a specific page.
So, looking at the diagram on the right, we can see that a virtual address points to a specific location on a virtual page. The virtual address contains a byte offset and several index values that are used to locate the page table entry that maps the virtual page into physical memory.
After the memory manager finds the page table entry, it uses the offset to find a byte in physical memory – identified by a physical address.
And there you have it – a quick look at the basics of Memory Management.
Address Space and Processes
A process is essentially, the combination of some executable code, a virtual address space and one or more threads of execution. The only way to increase the size of the virtual address space for a process beyond 4 GB, is to use 64 bit hardware with a 64 bit version of the operating system and application built for the 64 bit instruction set. The nub of it is, that no matter how much physical RAM is in the computer, the amount of memory available in the process’ private part of the virtual address space in 32 bit Windows implementations is limited to:
- 2 GB – without the /3GB switch – this is the normal, default maximum private virtual address space or
- 3GB with the /3GB switch or
- any physical RAM not used by the OS and other applications, by designing the application to use the AWE (Address Windowing Extensions) API.
With 64 bit operating systems, this 4 GB limit on address space is essentially removed.
Again: Virtual memory
This is a method of extending the available physical memory on a computer. In a virtual memory system, the operating system creates a pagefile, or swapfile, and divides memory into units called pages. Recently referenced pages are located in physical memory, or RAM. If a page of memory is not referenced for a while, it is written to the pagefile. This is called “swapping” or “paging out” memory. If that piece of memory is then later referenced by a program, the operating system reads the memory page back from the pagefile into physical memory, also called “swapping” or “paging in” memory. The total amount of memory that is available to programs is the amount of physical memory in the computer in addition to the size of the pagefile. An important consideration in the short term is that even 32-bit applications will benefit from increased virtual memory address space when they are running in Windows x64 Editions.
Applications that are compiled with the /LARGEADDRESSAWARE option, as would be required to take advantage of the /3GB switch in 32-bit Windows, will automatically be able to address 4 GB of virtual memory without any boot time switches or changes to x64 Windows. Plus, of course, the operating system does not have to share that 4 GB of space. Therefore, it is not constrained at all. We wil talk about the /3GB later.
Your RAM Memory is a limited resource, whereas virtual memory is, to a large extent, unlimited. When the memory is in use by all the existing processes and thus exceeds the amount of RAM available, the operating system will move pages (4 KB pieces) of one or more virtual address spaces to the computer’s hard disk, thus freeing some RAM for other uses. In Windows systems, these “paged out” pages are stored in one or more files with the name pagefile.sys. There can be one such file in each disk partition.
A frequently asked question is “how big should I make the pagefile”? There is no single answer to this question, because it depends on the workload on the computer, how much RAM there is and how much virtual memory space that workload requires. With operating systems like Windows XP, on older computers with a small amount of RAM, it is not uncommon for power users to have many windows open (and thus processes running) and to exhaust the available RAM. In this situation, the goal is provide sufficient pagefile space to avoid running out of available virtual memory, which could cause application failures or at least, significant inconvenience.
Most newer computers will have more than 2 GB of RAM and, in most cases, there is sufficient RAM available that having more virtual memory than the available RAM is a relatively rare occurrence. There is little point in allocating a large minimum size pagefile, since it typically won’t be used. However, having a relatively large maximum will avoid “out of virtual memory” conditions without dedicating a big chunk of disk space for that rare situation. A common objective in configuring a server is to ensure sufficient RAM so that paging doesn’t happen. Providing a large maximum pagefile is insurance against “out of virtual memory” situations that could cause service interruptions. Servers running a few applications are typically configured with enough RAM that paging is rare.
A common recommendation is to make the page file 1.5 times the size of the installed RAM. This recommendation makes sense only for computers with small amounts of RAM. For example, there is usually not much point in allocating a page file that is 96 GB if the computer has 64 GB of RAM. The objective in such RAM rich systems is to avoid using the pagefile at all by providing sufficient RAM that all virtual memory can be in RAM all the time. If the virtual memory in use exceeds the amount of installed RAM, performance will suffer and having a larger pagefile will not help this situation.
Windows only assigns space in the pagefile when a virtual memory page must be paged out. Thus the total available virtual memory is approximately the sum of installed RAM and the size of the pagefile(s). An argument sometimes made is that the minimum pagefile has to be at least the size of the RAM so that a full memory dump can be taken when the operating system crashes. However, this is not a very powerful argument. In the table , the increased maximum resources of computers that are based on 64-bit versions of Windows and the 64-bit Intel processor are compared with existing 32-bit resource maximums.
The operating system uses a small amount of space in the pagefile even when RAM is not exhausted, but in general terms, this is not particularly important. The main thing is that space in the page file will be allocated to virtual memory pages for which no corresponding RAM page is available. If the minimum and maximum pagefile sizes are not the same, the pagefile will initially be allocated to the minimum size, then expanded as more space is needed, up to the maximum. On most systems, this will mean that the pagefile will be fragmented, possibly in widely separated parts of the disk. If there is a significant amount of paging activity, this can lead to unnecessary performance degradation. Setting the minimum and maximum the same size may still result in a fragmented pagefile, but does reduce the likelihood of serious fragmentation. If the system is paging heavily and the pagefile is heavily fragmented, consider moving the pagefile to a newly formatted partition on a separate disk.
The best way to size the pagefile is to monitor how much of the pagefile is in use and the system paging activity. If very little of the pagefile is ever used, there is not much point in having a large minimum size. Conversely if the pagefile is typically 80% or more used, increasing the minimum size may be advantageous. For best performance when there actually is paging activity, the pagefile should be on a disk that is otherwise not used or that has very little activity. If possible, the page file should be created on a freshly formatted disk partition (or one that has been de-fragmented). This will usually ensure that the pagefile is contiguous on disk, thus minimizing head motion and increasing performance.
However, if there is significant paging activity, the best way to improve performance is to add more RAM. This will be far more effective in improving performance than any optimization of the pagefile location or size.
Resources: support.microsoft.com, Microsoft Technet, Bruce Sanderson, CC Hameed
See Monitoring RAM and Virtual Memory usage for more information about monitoring memory and pagefile use.