RAM, Virtual Memory, PageFile and all that stuff

Virtual Memory

In most 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. 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.

Address Spaces and Process

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.

Pagefile

RAM is a limited resource, whereas virtual memory is, to a large extent, unlimited in that there can be a large number of processes each with its own 4 GB virtual address space, of which 2 GB is private to the process (32 bit Windows). When the memory in use (that is, has been reference) by all the existing processes 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.

There is quite a variety of ideas on this subject, but here’s a place to start for computers (typically older ones) that don't have much RAM:

• If the computer has less than 1 GB of RAM
• Minimum – 384 MB
• Maximum – 1 GB (or less if disk space is in short supply)
  
• If the computer has more than 1 GB of RAM
• Minimum – 1 GB to the amount of RAM installed
• Maximum – 1 GB to the amount of RAM installed

Most newer computers will have more than I 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 possible exception are servers used for Terminal Services, where it would be common for some users to be relative inactive for long periods of time and paging may occur routinely without a significant performance penalty.

64 Bit Processors and Address Spaces

64 bit processor architectures provide virtual and physical address spaces greater than 4 GB, which can be advantageous for some applications. 64 bit architectures can provide other advantages to applications that are not directly related to the amount of addressable memory, but those are not discussed here. It is important to realize that a 64 bit architecture does not necessarily mean a 64 bit virtual or physical (RAM) address space is available. Processor, mother board, chip set and operating system design may well limit the available virtual or real addresses to less than 64 bits.

The size of the address spaces provided by these architectures appears, at this juncture, to be more than one could imagine using. However, history has shown that our ability to predict address space requirements for future systems has been pretty poor. For example:  The designers of the IBM 360 architecture in the early 1960’s provided a 16 MB address space (24 bits). RAM on those early mainframes was typically in the 10’s of Kbytes, so 16 MB was out of sight. By the 1970’s, 16 MB had already become a real limitation, so the architecture was changed to provide 31 bit (2 GB) address spaces, both virtual and physical. Why 31 instead of 32 bits had to do with the way backward compatibility for systems and applications designed and coded for the 24 bit address architecture was implemented.

 

The designers of the IBM PC architecture in the 1980’s said they could not conceive of anyone requiring more than 1 MB of memory (a 20 bit address space) on a PC (despite the relatively recent experience with the IBM 360/370 architecture!). By the end of the 1980’s, this was becoming a significant limitation that lead to the design of “expanded memory” (a form of memory mapping related to the AWE scheme implemented in Windows NT etc.) and “extended memory” – an enlarged address space.

Maximum RAM supported by 64 bit editions of Windows:

• Windows XP: 128 GB
• Windows Vista Home Basic: 8 GB
• Windows Vista Home Premium: 16 GB
• Windows Vista Business, Enterprise and Ultimate: 128+ GB
• Windows Server 2003 Enterprise Edition for Itanium: 64 GB
• Windows Server 2003 Datacenter Edition: 2 TB
• Windows Server 2003 Datacenter Edition for Itanium: 1 TB
• Windows Server 2003 R2 Standard Edition: 32 GB
• Windows Server 2003 R2 Enterprise Edition: 2 TB
• Windows Server 2003 R2 Datacenter Edition: 2 TB
• Windows Server 2003 R2 Datacenter Edition for Itanium: 2 TB
• Windows Server 2008 Web Edition: 32 GB
• Windows Server 2008 Standard Edition: 32 GB
• Windows Server 2008 Enterprise Edition: 2 TB
• Windows Server 2008 Datacenter Edition: 2 TB Windows Server 2008 for Itanium-Based Systems: 2 TB

See:

• http://www.microsoft.com/downloads/details.aspx?FamilyID=bbc16ebf-4823-4a12-afe1-5b40b2ad3725&DisplayLang=en (Windows Vista Product Guide - Windows Vista Editions Feature Table)
• http://www.microsoft.com/hk/server/windowsserver2003/evaluation/features/default.mspx
• http://www.microsoft.com/windowsserver2003/64bit/ipf/datacenter.mspx
• http://www.microsoft.com/windowsserver2008/en/us/compare-specs.aspx

Architectural limits for 64 bit Windows memory are:

• 8 TB of shared virtual address space for the system
• 8 TB of private virtual address space per process
• 128 GB System PTE storage
• 128 GB paged pool storage
• 128 GB non-paged pool storage
• 1 TB System cache
• 256 TB pagefile size

From http://support.microsoft.com/?kbid=294418 and http://www.microsoft.com/windowsserver2003/techinfo/overview/x64benefits.mspx.

Here’s some information from various sources about address space implementations in various 64 bit processor architectures from Intel and AMD.

Intel

Not all processors actually have (implement) the same number of physical and virtual address bits. However, all the relatively new processors support larger physical address spaces than are actually supported by any version of Windows, so the actual number of physical address bits implemented is somewhat irrelevant.

For virtual addresses, the operating system must ensure that it does not attempt to allocate virtual memory addresses using un-implemented virtual address bits because there will be application or system failures if it does. The processors provide a way for the operating system to determine the number of virtual address bits and thus the maximum useable virtual address actually implemented (e.g. on Itanium processors, the PAL_VM_SUMMARY "procedure" - see page 2-450 in

•  (http://download.intel.com/design/Itanium/manuals/24531805.pdf ).
• Itanium (see http://www.intel.com/design/itanium/itanium/itaniumprodbrief.pdf and http://download.intel.com/design/Itanium/manuals/24531805.pdf section 4.3.2)
• Physical Address - 44 bits - ~ 17,590 GB
• Virtual Address - varies by processor model - minimum 51 - ~ 2,250,000 GB Itanium 2 (see http://download.intel.com/design/Itanium/manuals/24531805.pdf)
• Physical Address 50 Bits - ~ 1,126,000 GB
• Virtual Address varies by processor model - minimum 51 - ~ 2,250,000 GB Intel Pentium, Xeon, Core 64 bit (see http://download.intel.com/design/processor/manuals/253665.pdf)
• Physical Address - varies by processor model - minimum 36 - 64 GB for most since 2004 Virtual Address 48 Bits (minimum) - ~ 281,000 GB

AMD

• Athlon, Opteron, Sempron and Turion:
• Physical Address 40 Bits - ~ 1,100 GB
• Virtual Address 48 Bits - ~ 281,000 GB Athlon - http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24659.PDF)
• Opteron - http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/23932.pdf
• Sempron - http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31805.pdf
• Turion - http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32816.pdf