Memory Management Confusion (a.k.a. What The Heck is PAE?)

Ok I want to get this one out of the way, since I end up answering these questions far too often…why there is no FAQ on this is beyond me.  PSE, PAE, and AWE.  People seem to understand that they all allow you to address more than 4GB of RAM on a 32bit CPU. Not everyone seems to understand the difference between them, or that there IS a difference.  PSE and PAE are features enabled by the CPU, AWE is Microsoft’s solution to allows applications to take advantage of this extra RAM.

PSE – Page Size Extensions.  Windows doesn’t support this particular feature, so I won’t spend time on it.  The important thing to know is that it’s not something you can just implement transparently.  You’d have to re-architect Windows…so, we didn’t.  Don’t ask for it, it’s not gonna happen. 🙂

PAE – Page Address Extensions.  This is the mechanism (again, enabled by the CPU) that allows CPU’s to address and Windows to manage more than 4GB of RAM.  The short explanation as to how this is works is that it adds another layer to the address translation scheme.  That allows a 32bit virtual address to be converted to a 36bit physical address.  The long version is best explained by Inside Windows 2000, by David Solomon and Mark Russinovich, and Chapter 3 of the IA-32 Intel Architecture Software Developer’s Manual, Volume 3: System Programming Guide.

AWE – Address Windowing Extensions.  These are the APIs Microsoft implemented to allow application developers to make use of the gobs of extra RAM PAE mode enables.  The Platform SDK has everything you need to know about the APIs, and how to use them is the subject better suited to a book than a blog.

Let me clear up the most common misconceptions that people have:

  • You do not need more than 4GB of RAM to use the AWE APIs.
  • The AWE APIs work on 64bit Windows.  If you’re writing a native 64bit app, it probably doesn’t make sense to use AWE, but the APIs are there and work as expected.  This allows 32bit apps running in the WOW64 subsystem on x64 platforms to allocate as much RAM as they can manage.
  • 32bit Windows cannot “see” all of the RAM in the system at once.  There is still a 4GB VA limit, which applies to the kernel as well as applications.  The memory manager has to choose which 4GB of RAM it can see at any one time, 2GB of which (unless you’re using the /3GB switch) is always the kernel memory space.  This is the reason we have to use the windowing method to allow applications access to all that extra RAM.
  • PAE and the /3GB feature do NOT play well together after a certain amount of RAM.  There’s a reason we cut off the usable memory at 16GB when you use both features.  IMO, even that is too generous.  The kernel runs out of memory to use for I/O and other critical functions far too soon.  If you have over 8GB of RAM, you should really test to see if you’ll get a performance benefit from using both before you just decide to do it!

This is a topic I could go on about for awhile, so I’ll just stop there for now.  I’ve seen enough information floating out on the web to know it’s dangerous…I might come back with more info later.

Comments (1)

  1. Kelley says:

    How about talking about DEP in SP2 and PAE?

Skip to main content