Take advatage of 4GB+ RAM in Windows 7 32-bit

[ksoren]

So, have you gotten the point? That your explanation of AWE and that it is required to address physical RAM located above 4G is wrong? That you cannot use AWE to explain what PAE is? That you can remove the existence of AWE and still use RAM above 4G?

[cluberti]

So, have you gotten the point? That your explanation of AWE and that it is required to address physical RAM located above 4G is wrong? That you cannot use AWE to explain what PAE is? That you can remove the existence of AWE and still use RAM above 4G?

Why don't you explain, as a developer, how you would allocate memory above 4GB on an x86 machine without the AWE APIs or the PAE kernel on Windows. I'd love to hear it.

[iamtheky]

http://support.microsoft.com/?kbid=283037

Without PAE, AWE cannot reserve memory in excess of 4 GB.

So, while your application that utilizes AWE will run just fine if you take /PAE out of your ini, and it will still allocate non-swappable memory; it will not do so above 4GB.

[ksoren]

Why don't you explain, as a developer, how you would allocate memory above 4GB on an x86 machine without the AWE APIs

As I've said, AWE is not about addressing physical memory. "Paging" is how you go from the virtual to the physical address space. PAE changes the page table layout so there are more addressing bits. A process' virtual address space can be mapped anywhere in physical ram. This has nothing to do with the application, but is a job for the memory manager (and the cpu which translates the application's virtual addresses into physical ones when needed).

The virtual address 0x1000 in a process can point to "0x1000 0000" or to "0x1 0000 0000", it doesn't matter, all the application sees is "0x1000". This is called paging (and is how the cpu handles memory).

The VAS is fixed at 4GB and cannot be changed. 2GB is default for user space. If the application for some reason needs to allocate more physical ram than can be mapped into these 2GB, it can make use of AWE. It will allocate a AWE-window and ask the memory manager to map it onto a physical area (which doesn't have to be contiguous). Later it can ask the memory manager to move the window. In this way the application can use wast amount of physical ram even though the VAS is only 2GB. But again, this is not PAE, this is just a technique for a single application to address more memory.

or the PAE kernel on Windows. I'd love to hear it.

This I have never said. What I have said is: you intermix PAE and AWE, and that is wrong.

Edited March 25, 2009 by ksoren

[cluberti]

As I've said, AWE is not about addressing physical memory.

Yes, it *is* about *directly* accessing memory addresses above the 4GB range and making them available - directly - via the window mapped out in your process space VA, via VirtualAlloc calls. Yes, yes, yes, yes it is about addressing physical memory. It's the *only* way on a Windows box to do so without writing a kernel mode driver to access (as some RAMDISK drivers do), and with some quite severe restrictions which I've already documented (being marked ReadWrite only, so no executable code, having to do your own memory management of the memory pages in the window, etc).

or the PAE kernel on Windows. I'd love to hear it.

This I have never said. What I have said is: you intermix PAE and AWE, and that is wrong.

I'm not debating this with you anymore. You've continuously said that I'm intermingling PAE (as in the PAE kernel) and AWE (as in the AWE API used to map memory above the 4GB boundary via VirtualAlloc calls), and that doing so is wrong, and yet someone who is so knowledgeable of Windows internals would know that on Windows these two are inextricably linked - one does NOT work as designed without the other, period.

More specifically, when I asked you specifically to tell me how to use the physical memory above 4GB without loading the PAE kernel or without using the AWE APIs on an x86 Windows system, you turn around and not answer the question but tell me that I'm wrong and that AWE is not about accessing physical memory - when in fact, it *is* about accessing physical memory above the 4GB boundary. So that's strike one. Ultimately, AWE *is* about addressing physical pages of RAM, via virtual memory addresses mapped into the process' VA, via the VirtualAlloc APIs.

Two, we're not talking about paging or writing physical RAM pages to a paging file or vice-versa, we're talking about mapping addresses above the 4GB boundary into the 2 or 3GB VA address range of a process calling the AWE APIs to do so. This has little or nothing to do with paging, it's about using the additional 4bits in the CPU to address the additional 32bits in the PTE. You are correct, the process sees a virtual address within it's 2 or 3GB VA, but the process must use the AWE APIs to map memory above 4GB into that window, and it *requires* that a PAE kernel be loaded, or the AWE API calls will work, but simply give you RAM addresses below the 4GB boundary. Since your answers indicate that you seem to think somehow this will magically work without the PAE kernel or AWE APIs on an x86 Windows machine, when in fact these are required, that's strike two.

Next, you continuously skirt my questions and respond with statements that show you do not understand this as deeply as you think. I asked a very simple question that for someone who's ever dealt with this should be able to answer quite easily, and you didn't. In fact, you responded with a response that had nothing to do with the question, meaning either you couldn't answer my question, or somehow you didn't understand it. Since I doubt it's the latter, and it's more likely to be the former, that's strike 3. Again, my question was very simple, and failure to provide an answer that would have supported your position makes it obvious to me that for someone who espouses to understand how this works, you do not. Just knowing the hardware side does *not* make you knowledgeable about how this is handled in Windows, and your answers bear out this fact. In Windows, AWE and PAE are inextricably linked, and you should know and understand this.

I'm done arguing this with someone who obviously hasn't developed in Windows against the AWE APIs and has maybe just read the Windows Internals book. You have no idea who you're talking to or what my expertise is, but from your answers I can see that you are *not* familiar with AWE or Windows above and beyond the Windows Internals book.

[Closed].