العربية
中国
Français
Deutsch
Ελληνική
हिन्दी
Italiano
日本語
Português
Русский
EspañolVIRTUAL MEMORY
:''This article is about the computer term. For the TBN game show, see Virtual Memory (game show).''
Virtual memory is an addressing scheme implemented in hardware and software that allows non-contiguous memory to be addressed as if it were contiguous. All current implementations of virtual memory support two operating system features:
# Memory can be addressed that does not currently reside in main memory and the hardware and operating system will load the required memory from auxiliary storage automatically, without any knowledge of the program addressing the memory, thus allowing a program to reference more (RAM) memory than actually exists in the computer.
# A multi-tasking system can provide total memory isolation, also known as a "discrete address space," to every task (except the lowest level operating system.) Isolation increases reliability by isolating faults within a specific task and preventing problems in one task from interrupting other tasks.
Hardware must have two methods of addressing RAM, real and virtual.
★ In real mode, memory address registers contain an integer that addresses a word or byte of RAM. The memory is addressed sequentially: if a program increments the address register by ''n'', the location of the memory being addressed moves forward by ''n''.
★ In virtual mode, memory is divided into pages, usually 4096 bytes long (see page size). These pages may reside in any available RAM location that can be addressed in virtual mode. Memory address registers are divided into an index and an offset: the high-order bits represent the index, and the lower-order bits represent the offset. The index is an offset within the page-mapping table (which resides at a known address in memory), each of whose entries contains the starting real addresses of the corresponding page. The offset represents a location within the page specified by the offset, and can range from 0 to 1 less than the page size (with a page size of 4096, between 0 and 4095). The virtual address is resolved by looking up the index in the page table -- yielding a physical page address -- and then adding the offset to the physical address.
The size of the tables is governed by the architecture and amount of RAM. All virtual addressing schemes require the page tables to start at either a fixed location or one identified by a register.
In a typical computer, the first table is an array of addresses, each of which denotes the start of the next array. The index into the first array is determined by certain high-order bits of the contents of the memory address register. Depending on the architecture, each array entry can be any size the computer can address. The next bits in the memory address register are an index into the array denoted by the first index. This set of arrays of arrays can be repeated, limited by the size of the memory address register.
The number of tables and the size of the tables vary by architecture, but the overall goal of virtual addressing is to transform the high order bits of the virtual address in the memory address register into an entry in the page table that either points to the location of the page in physical memory or to a flag that indicates the page is not available.
If a program references a memory location within a virtual page that is not available, the hardware generates a page fault. When this occurs, the memory management hardware invokes an operating system routine that loads the required page from auxiliary storage (''e.g.'', a paging file on disk) and turns on the flag that indicates the page is available. The hardware then adds the offset denoted by the low-order bits in the address register to the start location of the physical page, accesses the requested memory location, and returns control to the application that originally tried to access the memory. This process takes place transparently to the application addressing the memory. This scheme is called paging.
To minimize the performance penalty of address translation, most modern CPUs include an on-chip memory management unit (MMU) and maintain a table of recently used virtual-to-physical translations, called a Translation Lookaside Buffer (TLB). Translating an address that has an entry in the TLB requires no additional memory reference (and therefore time). However, the TLB can only contain a limited number of mappings between virtual and physical addresses. When the translation for the requested address is not resident in the TLB, the hardware will have to perform the translation and load the result into the TLB.
On some processors, address translation is performed entirely in hardware; the MMU has to make additional memory references to load the required translations from the translation tables, but no other action is needed. In other processors, assistance from the operating system is needed: the hardware raises an exception, and the operating system handles it by replacing a TLB entry with an entry from the primary translation table, and the instruction that made the original memory reference is restarted.
Hardware that supports virtual memory almost always supports memory protection mechanisms as well. The MMU may have the ability to vary its operation according to the type of memory reference (for read, write or execution) and the privilege mode of the CPU at the time the memory reference was made. This allows the operating system to protect its own code and data (such as the translation tables used for virtual memory) from corruption by an erroneous or malicious application program, and to protect application programs from each other and (to some extent) from themselves (e.g. by preventing writes to areas of memory that contain code).
Before the development of the virtual memory technique, programmers in the 1940s and 1950s had to manage two-level storage (main memory or RAM, and secondary memory in the form of hard disks or earlier, magnetic drums) directly. For example, using overlaying techniques.
Virtual memory was developed in approximately 1959–1962, at the University of Manchester for the Atlas Computer, completed in 1962. However, Fritz-Rudolf Güntsch, one of Germany's pioneering computer scientists and later the developer of the Telefunken TR 440 mainframe, claims to have invented the concept in his doctoral dissertation ''Logischer Entwurf eines digitalen Rechengerätes mit mehreren asynchron laufenden Trommeln und automatischem Schnellspeicherbetrieb'' (Logic Concept of a Digital Computing Device with Multiple Asynchronous Drum Storage and Automatic Fast Memory Mode) in 1957.
In 1961, Burroughs released the B5000, the first commercial computer with virtual memory.
Like many technologies in the history of computing, virtual memory was not accepted without challenge. Before it could be implemented in mainstream operating systems, many models, experiments, and theories had to be developed to overcome the numerous problems with virtual memory. Specialized hardware had to be developed to translate virtual addresses to physical addresses in primary or secondary memory. Some worried that this process would be expensive, hard to build, and take too much processor power to do the address translation.[1]
By 1969 the debate over virtual memory for commercial computers was over. An IBM research team led by David Sayre showed that the virtual memory overlay system consistently worked better than the best manually controlled systems.
Possibly the first minicomputer to introduce virtual memory was the Norwegian NORD-1 minicomputer. During the 1970s, other minicomputer models such as VAX models running VMS implemented virtual memories.
Virtual memory was introduced to the x86 architecture with the protected mode of the Intel 80286 processor. At first it was done with segment swapping, which becomes inefficient as segments get larger. The Intel 80386 introduced support for paging (coupled with segmentation.) The page fault exception could be chained with other exceptions without causing a double fault.
Virtual memory has been a feature of Microsoft Windows since Windows 3.0 in 1990. Microsoft introduced virtual memory in response to the failures of Windows 1.0 and Windows 2.0, attempting to slash resource requirements for the operating system.
Windows 3.x creates a hidden file named 386SPART.PAR or WIN386.SWP for use as a virtual memory swap file. It is generally found in the root directory, but it may appear elsewhere (typically in the WINDOWS directory). Its size depends on how much swap space the system has (a setting selected by the user under Control Panel → Enhanced under "Virtual Memory".) If the user moves or deletes this file, a blue screen will appear the next time Windows is started, with the error message "The permanent swap file is corrupt". The user will be prompted to choose whether or not to delete the file (whether or not it exists).
Windows 95 uses a similar file, and the settings for it are located under Control Panel → System → Performance tab → Virtual Memory. Windows automatically sets the size of the page file to start at 1.5× the size of physical memory, and expand up to 3× physical memory if necessary. If a user runs memory-intensive applications on a system with low physical memory, it is preferable to manually set these sizes to a value higher than default.
In NT-based versions of Windows (such as Windows 2000 and Windows XP), the swap file is named pagefile.sys. The default location of the page file is in the root directory of the partition where Windows is installed. Windows can be configured to use free space on any available drives for page files.
Occasionally, when the page file is gradually expanded, it can become heavily fragmented and cause performance problems. The common advice given to avoid this problem is to set a single "locked" page file size so that Windows will not resize it. Other people believe this to be problematic in the case that a Windows application requests more memory than the total size of physical and virtual memory. In this case, requests to allocate memory fail, which may cause the programs making the request (including system processes) to crash. Supporters of this view will note that the page file is rarely read or written in sequential order, so the performance advantage of having a completely sequential page file is minimal. However, it is generally agreed that a large page file will allow use of memory-heavy applications, and there is no penalty except that more disk space is used.
Defragmenting the page file is also occasionally recommended to improve performance when a Windows system is chronically using much more memory than its total physical memory. Although this can help slightly, performance concerns are much more effectively dealt with by adding more physical memory.
In the Linux and BSD operating systems, it is common to use a whole partition of a hard disk for swapping. However, with the 2.6 Linux kernel, swap files are just as fast[2] as swap partitions. Thus, this recommendation is of limited relevance to current Linux systems. As the flexibility of swap files can outweigh those of partitions, and modern high capacity hard drives can remap physical sectors, there is no guarantee that a partition will be contiguous. Even if it were, having the swap data near the rest of the data will reduce seek times when swapping is needed, so the aforementioned performance claims probably do not apply to modern Linux systems.
Linux supports using a virtually unlimited number of swapping devices, each of which can be assigned a priority. When the operating system needs to swap pages out of physical memory, it uses the highest-priority device with free space. If multiple devices are assigned the same priority, they are used in a fashion similar to level 0 RAID arrangements. This provides improved performance as long as the devices can be accessed efficiently in parallel. Therefore, care should be taken assigning the priorities. For example, swaps located on the same physical disk should not be used in parallel, but in order ranging from the fastest to the slowest (i.e.: the fastest having the highest priority).
There are also some successful attempts[3] to use memory located on the graphics card for swapping on Linux, as modern graphics cards often up to 512 megabytes of RAM that is normally only used when games are running. Video memory being significantly faster than HDDs, this method gives excellent swapping performance.
Recently, some experimental improvements to the 2.6 Linux kernel have been made by Con Kolivas, published in his popular -ck patchset[4]. The improvements, called "swap prefetch", employ a mechanism of pre-fetching previously swapped pages back to physical memory even before they are actually needed, as long as the system is relatively idle (so not to impair performance) and there is available physical memory to use. This gives several orders of magnitude faster access to the affected pages when their owning process needs access to them, since they are effectively not swapped out by then.
★ Page fault
★ CPU design
★ Memory management
★ System/38
{{FootnotesSmall|resize=
★ John L. Hennessy, David A. Patterson, ''Computer Architecture, A Quantitative Approach'' (ISBN 1-55860-724-2)
★ Virtual Memory Secrets by Murali
★ How Virtual Memory Works
★ Guide On Optimizing Virtual Memory Speed
★ Swap File vs. Paging File (Hint: From Windows 95 onwards, all Windows OS versions use only paging files.)
★ Linux swap partition
★ Linux Memory Management
★ Linux swap space management
★ Windows swap file management
★ Virtual Memory Page Replacement Algorithms
★ Linux Kernel Mailing List Discussion
★ Pointers to virtual memory visualizations
★ Windows XP. How to manually change the size of the virtual memory paging file
★ Windows XP. Factors that may deplete the supply of paged pool memory
★ SwapFs driver that can be used to save the paging file of Windows on a swap partition of Linux.
How virtual memory maps to physical memory
Virtual memory is an addressing scheme implemented in hardware and software that allows non-contiguous memory to be addressed as if it were contiguous. All current implementations of virtual memory support two operating system features:
# Memory can be addressed that does not currently reside in main memory and the hardware and operating system will load the required memory from auxiliary storage automatically, without any knowledge of the program addressing the memory, thus allowing a program to reference more (RAM) memory than actually exists in the computer.
# A multi-tasking system can provide total memory isolation, also known as a "discrete address space," to every task (except the lowest level operating system.) Isolation increases reliability by isolating faults within a specific task and preventing problems in one task from interrupting other tasks.
Overview
Hardware must have two methods of addressing RAM, real and virtual.
★ In real mode, memory address registers contain an integer that addresses a word or byte of RAM. The memory is addressed sequentially: if a program increments the address register by ''n'', the location of the memory being addressed moves forward by ''n''.
★ In virtual mode, memory is divided into pages, usually 4096 bytes long (see page size). These pages may reside in any available RAM location that can be addressed in virtual mode. Memory address registers are divided into an index and an offset: the high-order bits represent the index, and the lower-order bits represent the offset. The index is an offset within the page-mapping table (which resides at a known address in memory), each of whose entries contains the starting real addresses of the corresponding page. The offset represents a location within the page specified by the offset, and can range from 0 to 1 less than the page size (with a page size of 4096, between 0 and 4095). The virtual address is resolved by looking up the index in the page table -- yielding a physical page address -- and then adding the offset to the physical address.
The size of the tables is governed by the architecture and amount of RAM. All virtual addressing schemes require the page tables to start at either a fixed location or one identified by a register.
In a typical computer, the first table is an array of addresses, each of which denotes the start of the next array. The index into the first array is determined by certain high-order bits of the contents of the memory address register. Depending on the architecture, each array entry can be any size the computer can address. The next bits in the memory address register are an index into the array denoted by the first index. This set of arrays of arrays can be repeated, limited by the size of the memory address register.
The number of tables and the size of the tables vary by architecture, but the overall goal of virtual addressing is to transform the high order bits of the virtual address in the memory address register into an entry in the page table that either points to the location of the page in physical memory or to a flag that indicates the page is not available.
Paging
If a program references a memory location within a virtual page that is not available, the hardware generates a page fault. When this occurs, the memory management hardware invokes an operating system routine that loads the required page from auxiliary storage (''e.g.'', a paging file on disk) and turns on the flag that indicates the page is available. The hardware then adds the offset denoted by the low-order bits in the address register to the start location of the physical page, accesses the requested memory location, and returns control to the application that originally tried to access the memory. This process takes place transparently to the application addressing the memory. This scheme is called paging.
Translating the memory addresses
To minimize the performance penalty of address translation, most modern CPUs include an on-chip memory management unit (MMU) and maintain a table of recently used virtual-to-physical translations, called a Translation Lookaside Buffer (TLB). Translating an address that has an entry in the TLB requires no additional memory reference (and therefore time). However, the TLB can only contain a limited number of mappings between virtual and physical addresses. When the translation for the requested address is not resident in the TLB, the hardware will have to perform the translation and load the result into the TLB.
On some processors, address translation is performed entirely in hardware; the MMU has to make additional memory references to load the required translations from the translation tables, but no other action is needed. In other processors, assistance from the operating system is needed: the hardware raises an exception, and the operating system handles it by replacing a TLB entry with an entry from the primary translation table, and the instruction that made the original memory reference is restarted.
Protected memory
Hardware that supports virtual memory almost always supports memory protection mechanisms as well. The MMU may have the ability to vary its operation according to the type of memory reference (for read, write or execution) and the privilege mode of the CPU at the time the memory reference was made. This allows the operating system to protect its own code and data (such as the translation tables used for virtual memory) from corruption by an erroneous or malicious application program, and to protect application programs from each other and (to some extent) from themselves (e.g. by preventing writes to areas of memory that contain code).
History
Before the development of the virtual memory technique, programmers in the 1940s and 1950s had to manage two-level storage (main memory or RAM, and secondary memory in the form of hard disks or earlier, magnetic drums) directly. For example, using overlaying techniques.
Virtual memory was developed in approximately 1959–1962, at the University of Manchester for the Atlas Computer, completed in 1962. However, Fritz-Rudolf Güntsch, one of Germany's pioneering computer scientists and later the developer of the Telefunken TR 440 mainframe, claims to have invented the concept in his doctoral dissertation ''Logischer Entwurf eines digitalen Rechengerätes mit mehreren asynchron laufenden Trommeln und automatischem Schnellspeicherbetrieb'' (Logic Concept of a Digital Computing Device with Multiple Asynchronous Drum Storage and Automatic Fast Memory Mode) in 1957.
In 1961, Burroughs released the B5000, the first commercial computer with virtual memory.
Like many technologies in the history of computing, virtual memory was not accepted without challenge. Before it could be implemented in mainstream operating systems, many models, experiments, and theories had to be developed to overcome the numerous problems with virtual memory. Specialized hardware had to be developed to translate virtual addresses to physical addresses in primary or secondary memory. Some worried that this process would be expensive, hard to build, and take too much processor power to do the address translation.[1]
By 1969 the debate over virtual memory for commercial computers was over. An IBM research team led by David Sayre showed that the virtual memory overlay system consistently worked better than the best manually controlled systems.
Possibly the first minicomputer to introduce virtual memory was the Norwegian NORD-1 minicomputer. During the 1970s, other minicomputer models such as VAX models running VMS implemented virtual memories.
Virtual memory was introduced to the x86 architecture with the protected mode of the Intel 80286 processor. At first it was done with segment swapping, which becomes inefficient as segments get larger. The Intel 80386 introduced support for paging (coupled with segmentation.) The page fault exception could be chained with other exceptions without causing a double fault.
Windows example
Virtual memory has been a feature of Microsoft Windows since Windows 3.0 in 1990. Microsoft introduced virtual memory in response to the failures of Windows 1.0 and Windows 2.0, attempting to slash resource requirements for the operating system.
Windows 3.x creates a hidden file named 386SPART.PAR or WIN386.SWP for use as a virtual memory swap file. It is generally found in the root directory, but it may appear elsewhere (typically in the WINDOWS directory). Its size depends on how much swap space the system has (a setting selected by the user under Control Panel → Enhanced under "Virtual Memory".) If the user moves or deletes this file, a blue screen will appear the next time Windows is started, with the error message "The permanent swap file is corrupt". The user will be prompted to choose whether or not to delete the file (whether or not it exists).
Windows 95 uses a similar file, and the settings for it are located under Control Panel → System → Performance tab → Virtual Memory. Windows automatically sets the size of the page file to start at 1.5× the size of physical memory, and expand up to 3× physical memory if necessary. If a user runs memory-intensive applications on a system with low physical memory, it is preferable to manually set these sizes to a value higher than default.
In NT-based versions of Windows (such as Windows 2000 and Windows XP), the swap file is named pagefile.sys. The default location of the page file is in the root directory of the partition where Windows is installed. Windows can be configured to use free space on any available drives for page files.
Fragmentation of the Windows page file
Occasionally, when the page file is gradually expanded, it can become heavily fragmented and cause performance problems. The common advice given to avoid this problem is to set a single "locked" page file size so that Windows will not resize it. Other people believe this to be problematic in the case that a Windows application requests more memory than the total size of physical and virtual memory. In this case, requests to allocate memory fail, which may cause the programs making the request (including system processes) to crash. Supporters of this view will note that the page file is rarely read or written in sequential order, so the performance advantage of having a completely sequential page file is minimal. However, it is generally agreed that a large page file will allow use of memory-heavy applications, and there is no penalty except that more disk space is used.
Defragmenting the page file is also occasionally recommended to improve performance when a Windows system is chronically using much more memory than its total physical memory. Although this can help slightly, performance concerns are much more effectively dealt with by adding more physical memory.
Swapping in the Linux and BSD operating systems
In the Linux and BSD operating systems, it is common to use a whole partition of a hard disk for swapping. However, with the 2.6 Linux kernel, swap files are just as fast[2] as swap partitions. Thus, this recommendation is of limited relevance to current Linux systems. As the flexibility of swap files can outweigh those of partitions, and modern high capacity hard drives can remap physical sectors, there is no guarantee that a partition will be contiguous. Even if it were, having the swap data near the rest of the data will reduce seek times when swapping is needed, so the aforementioned performance claims probably do not apply to modern Linux systems.
Linux supports using a virtually unlimited number of swapping devices, each of which can be assigned a priority. When the operating system needs to swap pages out of physical memory, it uses the highest-priority device with free space. If multiple devices are assigned the same priority, they are used in a fashion similar to level 0 RAID arrangements. This provides improved performance as long as the devices can be accessed efficiently in parallel. Therefore, care should be taken assigning the priorities. For example, swaps located on the same physical disk should not be used in parallel, but in order ranging from the fastest to the slowest (i.e.: the fastest having the highest priority).
There are also some successful attempts[3] to use memory located on the graphics card for swapping on Linux, as modern graphics cards often up to 512 megabytes of RAM that is normally only used when games are running. Video memory being significantly faster than HDDs, this method gives excellent swapping performance.
Recently, some experimental improvements to the 2.6 Linux kernel have been made by Con Kolivas, published in his popular -ck patchset[4]. The improvements, called "swap prefetch", employ a mechanism of pre-fetching previously swapped pages back to physical memory even before they are actually needed, as long as the system is relatively idle (so not to impair performance) and there is available physical memory to use. This gives several orders of magnitude faster access to the affected pages when their owning process needs access to them, since they are effectively not swapped out by then.
See also
★ Page fault
★ CPU design
★ Memory management
★ System/38
Notes
{{FootnotesSmall|resize=
References
★ John L. Hennessy, David A. Patterson, ''Computer Architecture, A Quantitative Approach'' (ISBN 1-55860-724-2)
★ Virtual Memory Secrets by Murali
External links
★ How Virtual Memory Works
★ Guide On Optimizing Virtual Memory Speed
★ Swap File vs. Paging File (Hint: From Windows 95 onwards, all Windows OS versions use only paging files.)
★ Linux swap partition
★ Linux Memory Management
★ Linux swap space management
★ Windows swap file management
★ Virtual Memory Page Replacement Algorithms
★ Linux Kernel Mailing List Discussion
★ Pointers to virtual memory visualizations
★ Windows XP. How to manually change the size of the virtual memory paging file
★ Windows XP. Factors that may deplete the supply of paged pool memory
★ SwapFs driver that can be used to save the paging file of Windows on a swap partition of Linux.
This article provided by Wikipedia. To edit the contents of this article, click here for original source.
psst.. try this: add to faves
Featured Companies
| Great Time Travel | |
| Sheraton Vancouver Airport Hotel | |
| Optimum 1 Travel | |
| Aquaworld Cancun |
