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: hardware-boun...@hardwaregroup.com [mailto:hardware-
> boun...@hardwaregroup.com] On Behalf Of Soren
> Sent: Tuesday, August 03, 2010 6:24 PM
> To: hardware@hardwaregroup.com
> 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
> 


Reply via email to