KingTermite
05-27-2003, 08:53 AM
Here's an interesting article from Win Net Magazine I found about the Virtual Memory System (page file) (http://www.winnetmag.com/Articles/Index.cfm?ArticleID=595&pg=1&show=442) it's slightly old, but the Vitural Memory System hasn't changed much since Windows 3.1 so its still pertinent. BTW...there are a couple of other good articles about the Window VMS too...if anyone wants to read em.
Windows NT Paging Fundamentals
Christa Anderson (http://www.winnetmag.com/Authors/Index.cfm?AuthorID=2)
November 1997 Understanding NT's concept of memory management
If you've poked around in your system settings, you've probably seen the "paging file." You probably know that the paging file is the main on-disk repository for data that your programs need access to, but not necessarily right now. Somehow, Windows NT decides which data goes into the paging file and which data resides in physical memory.
There's a little more to it than that, however. In this article, I'll describe how this paging file works, what it does, and why you need it. First, I'll explain some basic concepts and structures associated with paging, and then I'll explore how paging and physical memory work together to affect your system's performance.
Virtual vs. Physical
When you refer to memory use under NT, it's important to know whether you're referring to physical memory or virtual memory. Physical memory is an easy concept to grasp--it's the amount of RAM installed on your system. Virtual memory, however, has nothing to do with the amount of physical memory installed but is the amount of memory that the operating system and the applications you're running perceive to be available: 4GB for each application. The amount of physical memory does not affect the amount of virtual memory available to each program. Whether your computer has 16MB or 600MB of RAM, each program will have 4GB of virtual memory.
Why 4GB of virtual memory? Because NT uses a 32-bit binary addressing scheme (i.e., each address in virtual memory has 32 bits), and 232 is equal to 4GB. Future versions of NT that use an addressing scheme with more bits will support an even larger virtual memory area.
The 4GB of virtual memory addresses available to each program are divided between user space and system space. User space, using the lower addresses, is private to each 32-bit program, and other programs ordinarily cannot manipulate it; 16-bit applications made for previous versions of Windows share a single address space, unless you specify otherwise at program startup. (If two 32-bit programs have a shared memory area set up, they can read and write to the data in each other's user address space, but this situation is the exception, rather than the rule.) System space, using the upper addresses, is common to all programs running on the system and to all components of the operating system. It's used for structures that all programs need access to.
Be aware that NT 4.0 divides the virtual addresses evenly between the user and system areas, providing 2GB of space for each. Adding Service Pack 3 (SP3) and running NT Enterprise Edition mean that you can boot NT 4.0 on an x86 system with a 3GB user address space, leaving 1GB for system space. NT 5.0 will always use the 3GB/1GB split for user addresses and system addresses.
Among the structures stored in system space are those used to translate between virtual and physical addresses. Translation? Well, yes: NT physically stores data into RAM, but all programs refer to virtual addresses, not physical ones. Translation between the two is necessary so that, for example, when a program requests the data stored at virtual address 2000000, it gets the data stored in physical address 45h.
Page Faults
What if a program requests data stored at virtual address 2000000, but no physical address is currently storing that data? This turn of events is fairly common, particularly when a program is just starting up, because NT starts applications with the least amount of memory necessary. In this case, an exception called a page fault occurs.
Unlike some other NT exceptions, a page fault isn't dire--it's simply how the operating system alerts itself that it can't do something that it's been directed to do under current circumstances, and other action is required. This exception is equivalent to you getting in your car without your car keys and realizing that you can't start the car without first getting out, retrieving the keys from the side table where you left them, and getting back in the car. This glitch doesn't mean your car won't start, but that you need to do something before it will.
NT's Virtual Memory Manager is responsible for handling page faults. The Virtual Memory Manager loads data into a physical memory address that can be translated into a virtual address for the sake of the process.
Page faults are normal occurrences: Except for the minimum needed to get a program going, no data is loaded into memory for the program. This method is NT's way of keeping memory usage to a minimum, ensuring that no application occupies physical memory that it doesn't need. Paging data into memory takes more time than just retrieving data from a physical memory address, but paging is a necessary part of the virtual memory system and better for system performance than forcing all program data to be locked into memory.
Working Sets
When a piece of a program's data is faulted into physical memory, it becomes part of that program's working set. A working set is not the minimum amount of data a program needs to function, nor the maximum, but simply the data that the program happens to be working with at the moment. Broadly speaking, a program's working set is a measure of the amount of physical memory that the program is using. This measure is only an approximate count, because some data included in the working set may be shared among several processes (DLLs are a common example), but that situation is typical of the relationship between working set and physical memory usage.
Working sets will grow and shrink depending on the demand for physical memory. A system thread called the balance set manager is responsible for taking data out of the working set if it hasn't been used for a while. If a serious demand for physical memory arises, the balance set manager may in fact trim every program's working set to a bare minimum (a value established at the time the program was started), requiring programs to fault pages back into memory as required.
Nonpageable Data
Not all data may be paged in and out of memory. All data stored in user virtual address space can be paged to disk when not in use, and most data stored in system space can also be paged, but any data that must be stored in a particular area of system space, called the nonpaged pool, cannot be paged. The reason for this limitation is not usually one of performance, but of necessity--some structures created from the nonpaged pool are those used to locate pageable data. (In addition to these pointers, the nonpaged pool includes device driver code and some other data.) The addresses that make up the nonpaged pool vary from platform to platform (i.e., they'll be different on an x86-based system from on an Alpha chip-based system). However, when you boot with the 2GB user and system address split, the addresses are around the middle of the system memory area of the 4GB virtual address space.
Windows NT Paging Fundamentals
Christa Anderson (http://www.winnetmag.com/Authors/Index.cfm?AuthorID=2)
November 1997 Understanding NT's concept of memory management
If you've poked around in your system settings, you've probably seen the "paging file." You probably know that the paging file is the main on-disk repository for data that your programs need access to, but not necessarily right now. Somehow, Windows NT decides which data goes into the paging file and which data resides in physical memory.
There's a little more to it than that, however. In this article, I'll describe how this paging file works, what it does, and why you need it. First, I'll explain some basic concepts and structures associated with paging, and then I'll explore how paging and physical memory work together to affect your system's performance.
Virtual vs. Physical
When you refer to memory use under NT, it's important to know whether you're referring to physical memory or virtual memory. Physical memory is an easy concept to grasp--it's the amount of RAM installed on your system. Virtual memory, however, has nothing to do with the amount of physical memory installed but is the amount of memory that the operating system and the applications you're running perceive to be available: 4GB for each application. The amount of physical memory does not affect the amount of virtual memory available to each program. Whether your computer has 16MB or 600MB of RAM, each program will have 4GB of virtual memory.
Why 4GB of virtual memory? Because NT uses a 32-bit binary addressing scheme (i.e., each address in virtual memory has 32 bits), and 232 is equal to 4GB. Future versions of NT that use an addressing scheme with more bits will support an even larger virtual memory area.
The 4GB of virtual memory addresses available to each program are divided between user space and system space. User space, using the lower addresses, is private to each 32-bit program, and other programs ordinarily cannot manipulate it; 16-bit applications made for previous versions of Windows share a single address space, unless you specify otherwise at program startup. (If two 32-bit programs have a shared memory area set up, they can read and write to the data in each other's user address space, but this situation is the exception, rather than the rule.) System space, using the upper addresses, is common to all programs running on the system and to all components of the operating system. It's used for structures that all programs need access to.
Be aware that NT 4.0 divides the virtual addresses evenly between the user and system areas, providing 2GB of space for each. Adding Service Pack 3 (SP3) and running NT Enterprise Edition mean that you can boot NT 4.0 on an x86 system with a 3GB user address space, leaving 1GB for system space. NT 5.0 will always use the 3GB/1GB split for user addresses and system addresses.
Among the structures stored in system space are those used to translate between virtual and physical addresses. Translation? Well, yes: NT physically stores data into RAM, but all programs refer to virtual addresses, not physical ones. Translation between the two is necessary so that, for example, when a program requests the data stored at virtual address 2000000, it gets the data stored in physical address 45h.
Page Faults
What if a program requests data stored at virtual address 2000000, but no physical address is currently storing that data? This turn of events is fairly common, particularly when a program is just starting up, because NT starts applications with the least amount of memory necessary. In this case, an exception called a page fault occurs.
Unlike some other NT exceptions, a page fault isn't dire--it's simply how the operating system alerts itself that it can't do something that it's been directed to do under current circumstances, and other action is required. This exception is equivalent to you getting in your car without your car keys and realizing that you can't start the car without first getting out, retrieving the keys from the side table where you left them, and getting back in the car. This glitch doesn't mean your car won't start, but that you need to do something before it will.
NT's Virtual Memory Manager is responsible for handling page faults. The Virtual Memory Manager loads data into a physical memory address that can be translated into a virtual address for the sake of the process.
Page faults are normal occurrences: Except for the minimum needed to get a program going, no data is loaded into memory for the program. This method is NT's way of keeping memory usage to a minimum, ensuring that no application occupies physical memory that it doesn't need. Paging data into memory takes more time than just retrieving data from a physical memory address, but paging is a necessary part of the virtual memory system and better for system performance than forcing all program data to be locked into memory.
Working Sets
When a piece of a program's data is faulted into physical memory, it becomes part of that program's working set. A working set is not the minimum amount of data a program needs to function, nor the maximum, but simply the data that the program happens to be working with at the moment. Broadly speaking, a program's working set is a measure of the amount of physical memory that the program is using. This measure is only an approximate count, because some data included in the working set may be shared among several processes (DLLs are a common example), but that situation is typical of the relationship between working set and physical memory usage.
Working sets will grow and shrink depending on the demand for physical memory. A system thread called the balance set manager is responsible for taking data out of the working set if it hasn't been used for a while. If a serious demand for physical memory arises, the balance set manager may in fact trim every program's working set to a bare minimum (a value established at the time the program was started), requiring programs to fault pages back into memory as required.
Nonpageable Data
Not all data may be paged in and out of memory. All data stored in user virtual address space can be paged to disk when not in use, and most data stored in system space can also be paged, but any data that must be stored in a particular area of system space, called the nonpaged pool, cannot be paged. The reason for this limitation is not usually one of performance, but of necessity--some structures created from the nonpaged pool are those used to locate pageable data. (In addition to these pointers, the nonpaged pool includes device driver code and some other data.) The addresses that make up the nonpaged pool vary from platform to platform (i.e., they'll be different on an x86-based system from on an Alpha chip-based system). However, when you boot with the 2GB user and system address split, the addresses are around the middle of the system memory area of the 4GB virtual address space.