OSNews

It's not this simple.

I don't know how Microsoft implemented this in practice, but the way I see it they only have a few choices :
-Having application developers swap data in and out of their application's address space all by themselves (cumbersome)
-Having applications not directly access their data, but only manipulate it through 64-bit pointers which are sent to the operating system for every single operation. They can do that e.g. by having the extra RAM being manipulated as a file (slow because of the kernel call overhead)

Really, PAE is only good for multiple large processes which each use less than 4GB. Having an individual process manipulate more than 4GB on a 32-bit system remains a highly cumbersome operation.

Edited 2011-01-06 20:04 UTC

32 bit Applications on Linux don't know they are on PAE or not. So application developers don't need to know about it.

A simple trick. Virtual memory ie swap out. To 32 be application this is what can appeared to have happened to the memory. Infact the memory block as just been placed in PAE Memory block outside the 4g address space. It way faster to get memory back using PAE than using swap.

Yes simple PAE treat it as a Ram based swapfile all complexity solved since 32 bit applications have to put up with swapfiles in the first place.

PAE is a good performance boost on 32 bit system running large applications that with 4 Gb limit would be running swap like mad. Yes Harddrive massively slow.

Now drivers and anything running in kernel mode is a different case. Lot of Windows drivers are not PAE huge memory aware. Even so there are ways around this issue while still taking advantage of PAE. Yes again drivers have to be swapaware or they will cause trouble. Being PAE aware does avoid having to pull page back into main memory for driver to place its data. Still way better than if that page had been sent to disk and had to be pulled back.

Basically there is technically no valid reason to limit particular version of windows to 4gb of memory. Heck Windows Starter has a fake limit of 1gb of memory. The 4gb limit was nice and simple to blame on 32 bit limit.

Cannot MS write a simple ram based swap system using PAE?

Yes it gets trickier with PAE 32 bit when you have duel core. Since to get most advantage out of PAE you have to use it for NUMA. Is this something applications need to worry about. Answer no.

Everything to support PAE is kernel based. Just has to be done right.

This is simply wrong.
"
Have you looked at my Bio? I work on Windows full time. If you want me to go over memory management, I can bore you to tears, but it's very unlikely that you'll be able to dismiss me that easily.

Firstly, here's the page that describes limits on physical addressing:
http://msdn.microsoft.com/en-us/library/aa366778(v=VS.85).aspx#physical_memory_limits_windows_7

Second, this section might be helpful (the part that talks about how PAE, /3Gb, and AWE are related and not related):
http://msdn.microsoft.com/en-us/library/aa366796(v=VS.85).aspx



That's all well and good, but it's still subject to the physical memory limits described in the link I gave above. See the part where it says "The physical pages that can be allocated for an AWE region are limited by the number of physical pages present in the machine, since this memory is never paged..." What this link really shows is that a single process, which has 2Gb of VA, can use greater than 2Gb of physical pages on a 32-bit client system. It cannot use more than 4Gb of physical pages, since that's the absolute maximum the client system will ever use.

It also shows that MS' implementation of AWE requires physical pages and is therefore unsuitable to extend addressing. On client systems it's only useful to get from 2Gb to (some value less than) 4Gb.

I'm sorry, I think we were talking past one another - I thought you meant that client versions of 32bit Windows had zero options to go past the 2GB limit for applications. We actually meant the same thing, except I was unaware of the 4GB limit of AWE. Thanks for clarifying!