just brew it! wrote:
OK, I'm gonna post this question here because I believe threads like this are made of 100% pure awsome...
Given a fully complient bios/motherboard, how much memory can I reasonably expect a 32-bit operating system, such as Window XP, to support (and properly use)?
For XP Pro, I believe the hard upper limit is 4GB of physical
But some of that won't be available because of overlap with device address space, as per BitVector's post that began this thread.
However, the various 32bit server
versions of Windows can make use of up 36bits (64GB) of physical memory via PAE, again as BitVector described. The actual limits for each version are given in this table
(including the funky Datacenter version that can go up to 128GB on special hardware).
Linux, given the right distro and build options, can use PAE in 32bits to get at all 4GB (again, provided your motherboard supports the necessary remapping of memory) or more if you have a server motherboard that supports >4GB of memory.
Individual user processes are still limited to 2GB of virtual RAM, unless the /3GB switch is used in the boot.ini file, and the application was built with the LARGE_ADDRESS_AWARE option.
Note, however, that PAE is somewhat incompatible with /3GB, because /3GB squeezes the OS down to 1GB of address space and PAE requires it to grow its data structures significantly to manage the extra memory, so /3GB effectively limits a server to 16GB of physical memory, even if more is installed.
But we're getting pretty far afield here, and the bottom line is this:
If you install 4GB of memory in your system, you will not see all of it unless:
1. Your motherboard supports remapping (or whatever it happens to be called in the bios) of memory that overlaps the PCI bus region
2. Your OS is either 64bit (of any sort) , 32bit Windows Server, or a 32bit Linux build that supports PAE (and turns it on)
Note that not all devices
are compatible with PAE. Devices see physical addresses, always (this is why we have this issue with physical RAM and DMA device addresses overlapping) and some of them can't handle addresses beyond the 4GB boundary (this is not a driver or OS issue, this is a "cutting corners to make cheap hardware" issue). On top of that, some otherwise-functional devices have drivers that blow up when they see addresses > 4GB. This is why Windows XP doesn't turn on PAE automatically to give you that full 4GB (even though it is using it internally to handle the xD/NX Data Execution Protection bit). The hardware compatibility list for Windows 2K3 Server is shorter than the list for Windows XP, and that's one of the reasons. That's also one of the reasons some devices don't, and will never, have 64bit drivers.
But here's the thing: even if everything works perfectly -- your hardware and drivers can handle those addresses, your motherboard supports remapping, and you're running a 32bit OS (Windows or
Linux) that turns on PAE so you see the full 4GB... you still aren't making optimal use of that memory. If you've got 4GB, you should be using a 64bit OS. Virtual memory management is built around a couple of fundamental assumptions, and one of those is that there's considerably more virtual address space than physical address space (ie, at least several times as much). When you're running a 32bit OS with 4GB of RAM, they're equal. And that creates problems: you get virtual address fragmentation, collisions, and other problems that cause the OS to work harder and less efficiently. PAE is a clever solution to a problem, but it is only a solution in particular circumstances, and most of those involve servers running certain workloads. It is a bad solution to the problem of using more than 4GB of physical memory for general purpose computing. The good solution is a 64bit OS.
If you've got 4GB, go 64bit. If you're thinking of getting 4GB, make sure your mobo supports remapping, and plan to go 64bit.
(Let me also take this opportunity to thank bitvector for starting a thread to pull this all into one place and for attempting to explain the issue and the solutions as clearly as possible.)