Slashdot Mirror
Behind the 4GB Memory Limit In 32-Bit Windows
An anonymous reader points us to a very detailed post by Geoff Chappell, first put up early this year, explaining how the 4GB memory limit commonly bandied about for 32-bit Windows (he is writing mainly about Vista) is more of a licensing preference than an architectural limit. The article outlines how Chappell unlocked his system to use all the memory that is present, but cautions that such hackery is ill-advised for several reasons, including legal ones. "If you want [to be able to use more than 4GB in Vista] without contrivance, then pester Microsoft for an upgrade of the license data or at least for a credible, detailed reasoning of its policy for licensing your use of your computer's memory. ... [C]onsider Windows Server 2008. For the loader and kernel in Windows Vista SP1 (and, by the way, for the overwhelming majority of all executables), the corresponding executable in Windows Server 2008 is exactly the same, byte for byte. Yet Microsoft sells 32-bit Windows Server 2008 for use with as much as 64GB of memory. Does Microsoft really mean to say that when it re-badges these same executables as Windows Vista SP1, they suddenly acquire an architectural limit of 4GB? Or is it that a driver for Windows Server 2008 is safe for using with memory above 4GB as long as you don't let it interact with the identical executables from Windows Vista SP1?"
Linux does not have the same limit
Does Microsoft really mean to say that when it re-badges these same executables as Windows Vista SP1, they suddenly acquire an architectural limit of 4GB? Or is it that a driver for Windows Server 2008 is safe for using with memory above 4GB as long as you don't let it interact with the identical executables from Windows Vista SP1?
Windows Server 2008 drivers have to be signed. For them to get signed, they can't do stupid shit like assume they are loaded in the memory space between 3GB->4GB, I'd imagine.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
On a 32-bit system a single process will always be limited to 4 GB due to the number of address bits, unless the programmer goes through hoops to access a larger memory area one small piece at a time (tricks like that were common in the DOS era -- anyone remember EMS?). On Windows the kernel typically reserves one half of the address space, cutting the usable memory of a single process down to 2 GB. Thus you won't get much advantage from a 64 GB capable kernel unless you run multiple programs that all require 1-2 GB of memory. Come to think of it, such usage is most likely on a server.
This sounds like more PAE shenanigans. Using PAE on 32 bit Windows has already been well covered by The Old New Thing.
So is that the reason that Linux has the same limit?
Unless I'm misunderstanding you and the summary (not RTFAed yet - I know, I'm bad) Linux doesn't necessarily have the same limitation. The summary seems to imply that only 4GB of *physical* memory are being supported on 32-bit systems by some versions of Windows. All OSes running on 32-bit x86 are restricted to a 4GB virtual address space, therefore neither Linux nor Windows can offer more than 4GB of directly addressable memory *per process*. But many 32-bit x86 CPUs can address more than 4GB of physical memory using PAE mode.
The base requirement for using PAE is that the OS supports it - Windows can use it, Linux can too. PAE gets you the ability to address physical memory addresses over 4GB but only if the motherboard has enough address lines to actually relay these requests to the memory. Even if you can't / don't have more than 4GB of RAM installed, it may still be worth it because PAE also lets you use NX (no execute) on 32-bit. PAE on 32-bit doesn't make the process address space any larger, so any given process is still limited to 32-bit pointers.
32-bit Linux has to be compiled with or without PAE support, so your distro should make sure it installs a the right kernel version to correctly support your hardware. Some OSes (e.g. Solaris) can switch between PAE and non-PAE at boot time, so they only need one kernel image to support both modes. I don't know how Windows handles this.
A further benefit of PAE, that I've left till last because it's really somewhat gross: the memory mapped IO regions used by PCI devices also take up part of your physical address space. This can result in a "memory hole" where your *real* RAM is overshadowed by an area of memory-mapped IO regions - the real RAM is there but you can't access it. As a result, if you put 4GB of RAM in your system and use a non-PAE kernel (only 4GB of physical address space) then you are *guaranteed* not to be able to use all that RAM because you will *definitely* have hidden some of it "behind" the memory mapped IO regions. If you use PAE mode, the motherboard can potentially remap that "hidden" RAM to a higher physical address, so that you can use it. Not all motherboards support this remapping, even if they *do* support 4GB worth of DIMMs - which is rubbish because they're claiming to support memory that the hardware will never let you actually address. It pays to be wary of this kind of craziness - my mobo has this limitation, which I discovered after buying 4GB of DIMMs (so I stuck one in another PC, which kept me happy in the end).
Uh, sorry to the parent poster, I've rambled a bit off the point I was originally making and probably just told you a load of stuff you already knew!