Thoughts from the EPS Windows Server Performance Team
In previous posts, we've discussed the Basics of Memory Management, Pool Resources and of course the /3GB Switch. Today we're going to take a look at the Virtual Address Space Layouts on a 32-bit system. We'll cover the 64-bit system specifics in a later post. First, let's cover some basic concepts dealing with the Virtual Address Space in Windows.
There are three main types of data that are mapped into the virtual address space in Windows:
As we discussed previously, each process has its own private address space that cannot be accessed by other processes unless they have permission to open the process for read or write access. Threads within the process cannot access virtual addresses outside the private address space unless they map to shared memory sections or use cross-process memory functions.
On systems with multiple sessions, such as Windows 2000 Server with Terminal Services and Windows XP and later operating systems, the sessions space contains information that is global to each session. A session consists of all the processes and other system objects that represent a single user's logon session. We covered Sessions, Desktops and Windows Stations a couple of months ago. All sessionwide data structures are mapped into a region of system space called session space. When a process is created, the range of addresses is mapped to the pages appropriate to the session to which the process belongs.
Finally, system space contains the global OS code and data structures that are visible to each process. The following components are part of the system space:
That covers the basic concepts of the virtual address space. Don't be too alarmed if you don't fully understand the individual components of the system space listed above - the key to remember is that there are three main data types to consider: Process, Session and System. With that in mind, let's take a look at the layout of Virtual Address Space on a 32-bit (x86) system.
If you recall, each user-mode process on a 32-bit Windows system can have up to 2GB of private address space, with the rest being reserved for the Operating System (we're assuming that the /3GB switch is not in play at the moment). The default address space is shown below on the left. On the right is what the address space would look like if you were to use the /3GB switch.
As you can see, the system-space is dramatically decreased. For more on how this effects PTE's and NonPaged Pool (among others) please refer back to our Demystifying /3GB post. Now, let's take a look at the different system variables and how they map to system space on systems with and without /3GB:
That brings us to the end of our overview of the 32-bit Virtual Address Space. We'll go over the 64-bit address spaces in a future post. Until next time ...
- CC Hameed
Great post! I often try to read the windows internals book but end up getting confused. I find this blog very helpful, well written and easy to understand.
Keep up these '101' type posts!
Is the PoolUsageMaximum registry entry and the KB article http://support.microsoft.com/kb/312362 relevant for 64-bit Windows Server 2003 Standard Edition? We have seen it help, but not sure if it proper to change it on 64-bit systems.
I'm looking for x64 Virtual Address Space topic, but I can't find in later topics... :(
This blog is good!!