So if DEP requires PAE on 32-bit Windows...why do some not see 4gb of ram?

D

dderidex

Supreme [H]ardness
Joined
Oct 31, 2001
Messages
6,328
As above.

The best explanation I've seen for the "I have 4gb, but the OS only shows 3.5gb" is found on this page (including a spiffy graphic! :p). Thing is, and as there noted, the overall solution advised is "enable PAE, and the OS will be able to see the 4gb". Fine and well, that matches my understanding of how PAE extends the 32-bit Windows OS's ability to reference memory by creating a 'buffer' to make a virtual 36-bit address space.

But, here is the problem that brought out this question.

DEP on 32-bit Windows OSes requires PAE. If you have DEP enabled, you have PAE enabled, whether you set the switch in the boot.ini or not. This according to Microsoft, themselves:

To use these processor features, the processor must be running in Physical Address Extension (PAE) mode. However, Windows will automatically enable PAE mode to support DEP. Users do not have to separately enable PAE by using the /PAE boot switch.
Click to expand...

...which is why I wonder about the number of "I only see 3.5gb, when I have 4gb" questions. Virtually EVERY SINGLE processor released in the past 5 years has DEP support (either via AMD's NX bit or Intel's XD bit). So, installing a clean Windows to a box with one of these processors, it by default enables DEP. I've not seen a single system without that enabled in a very, very long time, now. Ergo, PAE is also enabled, and...

...well, back to the title. Why would anyone not see all 4gb of ram, then? If PAE allows it to be seen, and PAE is automatically enabled when DEP is present, and DEP has been present on every proc even remotely modern...???
 
You are using all 4GB's of ram. Your motherboard, cpu, graphics cards etc all count towards that limit.

Go to your device manager. Click view, sort by resource type. Then open up the memory drop. You should have about 30 devices listed. ALL of those use ram and it counts from 4GB down. Whatever is left after those resources get ram, is left for your applications, which is usually around 3.5GB.

Don't even think a second more about PAE because that has nothing to do with your home OS, it's a 'Server' only feature. DEP is used to prevent corruption and applications to run from memory that may harm your computer. Leave DEP on, ignore everything you know about PAE unless you run "Server" labeled 32 bit OS.
 
Did you read the linked MS KB article?

If you have a 32-bit OS, and DEP is on, you have PAE on. Period. You can't have DEP without PAE.
 
PAE is enabled when DEP is enabled on 32-bit Windows OSes, and PAE can be used to address more than 4GBs of Ram, however the ability to address > 4GBs of RAM in 32-bit home windows editions (specifically XP Pro/home, and Vista and almost certainly Windows 7, although I think Win2K doesn't have this limit) is disabled because of driver incompatibility issues. So everything goes to addresses below 4GBs, including some video and sound ram, and whatever other device needs ram, leaving you with less than 4GBs of ram to use when you have 4GBs or more of ram installed.
 
devil22 said:
PAE is enabled when DEP is enabled on 32-bit Windows OSes, and PAE can be used to address more than 4GBs of Ram, however the ability to address > 4GBs of RAM in 32-bit home windows editions (specifically XP Pro/home, and Vista and almost certainly Windows 7, although I think Win2K doesn't have this limit) is disabled because of driver incompatibility issues. So everything goes to addresses below 4GBs, including some video and sound ram, and whatever other device needs ram, leaving you with less than 4GBs of ram to use when you have 4GBs or more of ram installed.
Click to expand...

Completely Correct. PAE is scaled back in 32 bit home O/S, due to lots of consumer class hardware, freaking out when handed a true 32 bit address. (Not the usual 31 bit address)

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Ranma_Sao said:
Completely Correct. PAE is scaled back in 32 bit home O/S, due to lots of consumer class hardware, freaking out when handed a true 32 bit address. (Not the usual 31 bit address)

This posting is provided "AS IS" with no warranties, and confers no rights.
Click to expand...

I understand this is true of XP 32-bit, but I was under the impression this was changed with the updated driver model for Vista 32-bit.
 
No, it wasn't changed for Vista. MS probably figures you should just go 64-bit if you want more than 4GBs of Ram in Vista, and with the way 64-bit drivers are mandatory, there is no reason not to. I'm not privy to exactly what reasons they have, but I'm sure it 1. reduces the amount of testing vendors and MS have to do, since they only have to test 32-bit and 64-bit, instead of 32-bit, 64-bit and 32-bit PAE 2. 64-bit is a cleaner architecture than PAE 3. PAE has a performance hit. Etc.

Since almost every device that has a 32-bit vista driver has a 64-bit one as well, might as well just get everyone on 64-bit and skip the PAE nonsense. It's not like XP where 64-bit drivers were seriously lacking.
 
devil22 said:
2. 64-bit is a cleaner architecture than PAE 3. PAE has a performance hit. Etc
Click to expand...

2) Maybe, because driver vendors might be more aware that something actually exists above 4G, and their drivers therefore will not break.

3) Are you forgetting that DEP is default, and therefore PAE also is?
 
3) Are you forgetting that DEP is default, and therefore PAE also is?
Click to expand...

http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx

3. Application Windowing
A PAE-enabled operating system can introduce an API to allow a properly coded application access to physical memory anywhere in the system, even though it may be above 4 GB. Ideally, the API to allocate "high" physical memory and create or move the window should be quick and simple to code. This is highly advantageous for applications that require fast access to large amounts of data in memory.

Sharing high memory between processes can introduce quite a bit of complexity into the API and the implementation. Windows avoids this kind of sharing.

In addition, the support of paging makes the design and implementation of the operating system much more difficult and makes deterministic performance more difficult to achieve. Windows avoids paging of high memory as well.
...
Obviously, DAC or 64-bit adapters and drivers provide the best performance as no buffering of I/O occurs. This buffering is required, however, whenever the adapter and driver cannot utilize more than 32 bits of address information. All operating systems that utilize PAE mode addressing support this "double buffering" in some fashion, as a backward compatibility feature. This buffering does have a performance penalty that is dependent on several factors:

• Adapter hardware performance

• Driver performance

• Operating system support provided for double buffering

• Amount of physical memory installed in the system


As the physical memory increases, the relative amount of I/O addresses beyond 32 bits also increases in relation to those addresses below 32 bits. In most cases, the operating system transparently provides double buffering, although some Unix variants do not provide any assistance in this function and require any 32-bit devices and drivers to manage their own double buffering routines and allocations.
Click to expand...

So this says a performance hit is incurred on i/o above 4GBs, if I'm reading it correctly. So 32-bit XP and 32-bit Vista would not be affected. Honestly I'm going by the above and what I heard, if you know more, then I'd welcome any additional information.
 
AWE is an optional component that applications can use to address more memory than can be expressed in their virtual address space. It is not PAE.

I/O addressing above 4G has the same limitations in a 64bit OS.
 
pallesen said:
3) Are you forgetting that DEP is default, and therefore PAE also is?
Click to expand...

I linked an MS KB above noting exactly that. Since XP SP2, actually, you can't disable it - DEP and PAE are always on for 32-bit XP.
 
pallesen said:
AWE is an optional component that applications can use to address more memory than can be expressed in their virtual address space. It is not PAE.

I/O addressing above 4G has the same limitations in a 64bit OS.
Click to expand...

The article parts I quoted said PAE has double buffering and it incurs a performance penalty, so what does that have to do with AWE? And if you have some link confirming your assertion about 64-bit OSes having a double buffering or other I/O limit above 4GBs, could you post it?
 
dderidex said:
I linked an MS KB above noting exactly that. Since XP SP2, actually, you can't disable it - DEP and PAE are always on for 32-bit XP.
Click to expand...

It doesn't matter, your question was why do XP and Vista 32-bit users not have access to 4GBs+ of memory even though they run in PAE, the answer is MS disabled that ability, the reasons I speculated on but are what I've heard smart people say over the years but are totally irrelevent to the answer to your question.
 
devil22 said:
It doesn't matter, your question was why do XP and Vista 32-bit users not have access to 4GBs+ of memory even though they run in PAE, the answer is MS disabled that ability, the reasons I speculated on but are what I've heard smart people say over the years but are totally irrelevent to the answer to your question.
Click to expand...

PAE gives access to 64Gig of address space on a 32bit Operating system
Yes MS crippled this for servers and for home-users

but in all honesty IF you have a 64bit CPU and >2gig of RAM you really should be using a 64bit Operating system
 
devil22 said:
The article parts I quoted said PAE has double buffering and it incurs a performance penalty, so what does that have to do with AWE? And if you have some link confirming your assertion about 64-bit OSes having a double buffering or other I/O limit above 4GBs, could you post it?
Click to expand...

Double buffering can come in play, when you have DMA buffers above 4G. This can also happen in a 64bit OS.

AWE is what you quoted about "A PAE-enabled operating system can introduce an API to allow a properly coded application access to physical memory anywhere in the system"

Edit: About I/O addressing. This is something that takes place outside the CPU. So what kind of OS you install cannot possible change what happens here.
 
Again, do you have a link saying 64-bit OSes suffer from double-buffering above 4GBs? Because the article from MS clearly states:

Obviously, DAC or 64-bit adapters and drivers provide the best performance as no buffering of I/O occurs.
Click to expand...

You are directly contradicting MS here, so post your source.
 
But the impression I got from your original comment on the subject is that all 64-bit drivers suffer this, whereas the link you posted makes it very clear that only improperly written drivers suffer from buffering (or double-buffering) in 64-bit OSes, I would think this would be exceedingly rare in a modern OS like Vista x64.
 
The bad drivers are those that fucks up the system. Double buffering doesn't even come into play here. The bad drivers are the reason why Microsoft cut off access to anything above 4G.

Double buffering is relevant when you have good drivers (32 or 64bit ones), which talks to hardware that cannot do 64bit addressing, and have their dma buffers located above 4G.
 
Can 32-bit drivers that run in PAE mode talk to hardware above 4G without double-buffering? If not, then I still think it's fair to say PAE has a performance hit, overall, considering the industry is probably moving towards proper hardware support of 64-bit. Really, I can't see the point of debating this all day, PAE addressing above 4G is dead and 64-bit is the king now, and that's how it should be.
 
of cause PAE has a performance hit...

at best it 1/2 the bandwidth of RAM access

you basically have to send 2x32bit words to get a memory location duuur 1/2 the bandwidth
 
devil22 said:
Can 32-bit drivers that run in PAE mode talk to hardware above 4G without double-buffering? If not, then I still think it's fair to say PAE has a performance hit, overall, considering the industry is probably moving towards proper hardware support of 64-bit. Really, I can't see the point of debating this all day, PAE addressing above 4G is dead and 64-bit is the king now, and that's how it should be.
Click to expand...

Yes, they sure can. Remember, that the limitation is not in the (correctly written) driver, but in the hardware it communicates with.

eeyrjmr said:
of cause PAE has a performance hit...

at best it 1/2 the bandwidth of RAM access

you basically have to send 2x32bit words to get a memory location duuur 1/2 the bandwidth
Click to expand...

Sorry, but that is a total misunderstanding of how it works.
 
pallesen said:
Sorry, but that is a total misunderstanding of how it works.
Click to expand...

Sorry but no

Fundementally that is basically what is going on

32bit system can only address ... 2^32 unique addresses. lets crudely say that is... 4Gig

Say a system that is PAE-enabled has 8gig installed it can't send a single 32bit word to address the RAM since that will ONLY address 4Gig's of RAM. A 2nd 32bit word is needed to act as a page (since in PAE RAM is grouped into banks for 4gig)

THUS to address memory in a PAE-enabled system you must
1) send a 32bit word to tell the controll what band
2) send a 32bit word to request a r/w from the selected bank

THUS 2 32bit words need to be sent where only 1 needs to be sent in a non-PAE,<4gig system

Ergo 1/2 the bandwidth...


There is no way you can equal the memory access of a non-PAE system let alone equal. At best you are looking at 1/2 the bandwidth

You then gotta factor in the kernel has exclusive access to the 1st gig of RAM locations (NORMAL_ZONE) and everything else resides in HIGHMEM_ZONE and thus is non-priority access which adds additionallatency when accessing HIGHMEM_ZONE locations
 
No, it does NOT work like that. And there is no banks of 4GB.

intel.com and amd.com have some detailed info about how it works.
 
You must log in or register to reply here.
Back
Top