How Memory is Managed by the OS


Your memory must support both the operating system’s (kernel) processes and user (private) processes. These steps happen when a you start a program.

  1. The operating system creates an address space for the program to run in, which involves setting up appropriate page tables.
  2. The program’s text and data segments are mapped from the executable file on disk to the virtual address space; the text being mapped as read only, the data being mapped as read-write.
  3. The stack and heap are initialized. (Whatever it means..forget it for this moment)
  4. Control is transferred to the program.
  5. The processor tries to access the first instruction. Since it is not in memory, a page fault is generated.
    This causes the operating system to intervene and allocate one or more pages of physical memory and to copy the code from the file. There you get the name: “Demand Paged Virtual Memory.”
  6. The processor then returns control to the program, which continues executing until it encounters another page fault. At this point, step 5 is repeated.
  7. If there is no free physical memory, the operating system will have to
    1. either discard (if read only) or
    2. swap out (write data to swap file if read write) pages before they can be reused.
  8. Typically a least recently used (LRU) algorithm is used for deciding which pages get tossed.
  9. This pattern continues for the life of the program.

When you executes a program, the operating system creates an address space for it to run in. This address space will include the instructions for the program itself, as well as any data it requires.

In a system with memory protection, each process is restricted by the operating system to access only the memory in its own address space. However, the combined program memory requirements often exceed the system’s amount of physical memory installed on a computer. Therefore your operating system uses a portion of the hard disk called a swap file to extend the amount of available memory. This technique, called virtual memory, treats physical memory as a cache of the most recently used data.

In a virtual memory system, memory is divided into units called pages. A page is typically 4-8 KB in size. The set of addresses that identify locations in virtual memory is called the virtual address space (VAS). Each process is allocated a virtual address space. The virtual address space can range from zero to 4 GB on a 32-bit architecture.

A process’s address space contains the set of instructions and data that is mapped into virtual memory when a program is executed. Virtual memory addresses are translated into physical memory addresses through the use of a look-up table, called a page table. In addition to mapping the entire process into virtual memory, a subset of pages is also mapped into physical memory. As each instruction in the process executes, it is either found in physical memory or is not found (called a page fault).

When a page fault occurs, the page that is needed must be moved from the hard disk into physical memory before the instruction can be executed. To make room for the new page, the operating system may need to decide which page to move out of physical memory. This is called swapping. A page fault is time consuming because retrieving data from the hard disk is much slower than obtaining it directly from the physical memory. Operating systems attempt to minimize the number of page faults by swapping multiple pages at once. This becomes a trade-off between operating system overhead and the time saved by minimizing page faults, which is affected by the size of each process’s working set.

The operating system takes care of swapping and translating from virtual address space to physical address space. With a virtual memory scheme, the amount of memory available is seemingly limited only by the amount of hard drive space. Virtual memory has more memory available than physical memory because it removes the restriction that an entire process must be loaded into memory at one time.

Now read (if you did not already) the post about OOM Errors

Why Do I Get Out-of-Memory Errors


Virtual memory refers to the ability of your computer to use your hard drive as if it were the random access memory (RAM) of your computer. This ability is present on all operating systems. Thus, if you have a lot of hard drive space, it might appear that memory is almost unlimited. So why do you get still unpredictable out of memory (OOM) errors?

One cause of OOM errors is that your system has run out of space to hold all of your variables. This means that there is no unallocated virtual address space enough on your computer for programs used by e.g. FSX or P3D and therefore no new variables can be created.

Secondly OOM errors are caused by memory fragmentation. This means that there is memory available, but there is no contiguous piece of memory that is large enough to hold specified variables. When virtual memory is used and freed during normal operation of programs, memory becomes fragmented. This means that the amount of total free memory is greater than or equal to the amount of contiguous free memory. Since variables must be stored in a contiguous block of virtual memory, the largest space, which can be created at a any point in time, is limited by the amount of contiguous free virtual address space.

32-Bit Architecture
For PC’s with 32-bit architectures, the size of a processor instruction (a pointer) can be max. 32 bits long. This limitation implies that the memory addresses can be a maximum of 32 bits long, which results in a maximum of 2^32 possible memory addresses. This translates into 4 gigabytes (GB) of addressable memory. Therefore in a 32-bit architecture, the seemingly unlimited virtual memory space is actually limited to approximately 4 GB. The Windows 32-bit operating system reduces the theoretical limit down to 2 GB of virtual memory due to a design decision to reserve the upper 2 GB of address space. On some versions of Windows, this limit can be moved to allow for an extra 1 GB of memory using the /3GB switch.

64-Bit Architecture
If you are using a 64-bit operating system in conjunction with a 64-bit version of a program, (and FSX nor P3D is not) it is in theory possible to access about 2^64 bytes of memory. This means that the amount of memory that is available to programs, will be limited by the amount of memory available on the computer. As this is typically related to the amount of available virtual memory or page file size, you may want to read here how to manage the virtual memory size.

How to configure the pagefile.

For Windows 7/8

  • Right-click on Computer
  • Select Properties.
  • Select the Advanced System Settings
  • Click on the Advanced tab and then Settings under Performance.
  • In Performance Options click on the Advanced tab
  • and then click on Change under Virtual Memory.

Under Automatically Manage Paging File Size, click on Custom Size to enter the amount of swap space in MB and follow the recommendations in this screen.

Better is to set the checkbox @ Automatically manage paging file size for all drives

All about RAM, Virtual Memory and Pagefile


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.

Virtual memory in Windows 32-bit operating systems

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.


Addresses and Spaces

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.


Pagefile
This is a disk file that the computer uses to increase the amount of physical storage for virtual memory

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.