The article you linked actually proves my point. While the kernels of the MS client OS editions are technically capable of using PAE and, therefore, memory above 4GB, that memory is ignored or otherwise intentionally and actively disabled.
>From http://geoffchappell.com/notes/windows/license/memory.htm: "The 32-bit editions of Windows Vista all contain code for using physical memory above 4GB. Microsoft just doesn't license you to use that code.", then he shows screenshots of a Vista Ultimate 32-bit system with 8GB of memory installed. However, note this line that follows after the screenshots: "...to simulate having new license data from Microsoft, I have modified the kernel just enough so that it ignores the two license values that set memory limits, and I have started Windows in Test Mode so that it tolerates a kernel that no longer has Microsoft's digital signature." Granted, that's Vista, but the author then talks about changes made to the HAL in Windows XP beginning with SP2 (and continued in SP3) that actually makes memory above the 4GB address space unusable. From the KB article that the author references as admission of the change: " Any system RAM that is more than the 4 GB barrier would be made unaddressable by Windows and be unusable in the system." I did learn something here: apparently, XP RTM and XP SP1, while only licensed for 4GB, did not actively prevent using memory above the 4GB address space when PAE was enabled. It's likely this is simply because 4GB was extremely uncommon during the timeframe that RTM/SP1 were considered "current" patch levels. XP Professional and Corporate Edition (I assume that by CE you mean Corporate, not XP Embedded) are no different than Home in this regard. Basically, the whole page is a long winded explanation stating that Windows is technically capable of using more than 4GB on a 32-bit system by using PAE, but Microsoft actively disables this functionality in client operating systems beginning with XP SP2. I didn't realize that it wasn't enforced prior to SP2, but it's still essentially the argument I made from the beginning. NUMA is Non Uniform Memory Access. The idea here is that in modern multi-socket systems that feature processors with integrated memory controllers, not all of the address space is created equal. Processor A has its own local memory, as does Processor B. While the memory attached to processor B is available to threads executing on processor A, it must go through processor B to get to it, which introduces extra latency. Operating systems try to reduce this performance hit by trying to run threads on the processor that has the thread's memory local to it. Apparently, Microsoft chose to implement this NUMA-awareness in the PAE version of their kernels. Greg > -----Original Message----- > From: [email protected] [mailto:hardware- > [email protected]] On Behalf Of Soren > Sent: Tuesday, August 03, 2010 6:24 PM > To: [email protected] > Subject: Re: [H] new system build suggestions or upgrade > > I know I'm mistaking when it comes to XP Home, but Pro/CE versions are > different creatures, as you already know. > > As Mr. Phiber correctly pointed out, no process can use more than 3GB RAM. > (Hence the urban legend about XP/Vista not supporting more than 3GB > RAM, which btw is almost true with the Home edition, which we all, of > course, try to avoid :) > > 3GB/process is plenty when using an AV system, as separate processes often > are executed at the same time, using different processors, sometimes by > direct allocation. > > What's NUMA? (never heard of it, or I don't remember - I'll look it up) > > Most apps for professional audio recording make use of the AWE API. I'm not > sure about professional image rendering progs, but the two systems I've > built for this purpose make plenty use of the 32GB installed. And this > happens with a default installation of the OS (XP CE). > > To my knowledge, the PAE boot switch is only used if one wants to allocate > more than 3GB RAM to the OS. > > Thanks for the link, but I don't trust the MS sites about RAM and OS's > anymore... > > Soren >
