nauseaboy (reaverxvx) wrote in linux,

32 bit OS and 4GB of memory.

I recently ran into this forums thread concerning Vista and it's 4GB of RAM problem, and I'm wondering if this issue is specific to the Windows 32-bit Operating System or if this is a hardware bottleneck that you run into running any 32 bit operating system?

From the TFA:

"Various devices in a typical computer require memory-mapped access. This is known as memory-mapped I/O. For the MMIO space to be available to 32-bit operating systems, the MMIO space must reside within the first 4 GB of address space.

For example, you have a 8800GTS 640Mb Graphics card. That cards memory MUST be mapped withing the first 4Gb of address space. If you have 4Gb of memory installed then part of the addresses are reserved for the graphics card memory map. The graphics card memory now OVERWRITES a part of the system memory. 4Gb = 4096Mb - 640Mb = 3456Mb. If you have 2 GTS 640Mb then the amount of TOTAL RAM available to the O.S. becomes even less and so on. The amount system memory is reduced is all dependent on the amount of devices installed in the system. However, to avoid potential driver compatibility issues, the 32-bit versions of Windows XP/Vista limit the total available memory to 3.12 GB."

So i'm wondering if linux users are running into this same issue were they've got 4GB of RAM installed but are only seeing a little more than a 2? Or are you guys seeing the full amount?
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 



February 28 2008, 09:42:11 UTC 6 years ago

its less than 4GB its more like 3.37gig
its a problem with all 32bit OSs though.

Luckily most Linux distro's come in 2 flavours. the i386 for systems with a 32bit processor and a 64bit version.

personally i use 64 studio on one of my PC's and Ubuntu (Gutsy) 64bit on my other. and they are a bit quick when doing things, even when i VM windows they are still very responsive.

But TBH, 4gb is overkill unless you are doing some serious stuff. (i use mine for image and sound processing with a little bit of film editing)

and 3gig will happily run any game thats currently on the market.
most home users only really need 512 to 1gig for what they do.

also, if you want to run more with windows, they do do a 64 bit version of xp pro and vista. but it puts the price up and it has issuses with some of the software tat was designed for the standard release of windows.



February 28 2008, 12:12:30 UTC 6 years ago

Not even an O/S limitation, it's an 80x86 architecture limitation that dates all the way back to the '80s. Even then, you wanted to blit a screen to your graphics card you set up a char array, gave it all the data you wanted in the right order and memcpy(oxa0000000, screenBuffer).


February 28 2008, 17:27:32 UTC 6 years ago

I think this comment by theswede explains it.

You're talking about physical address space, and that's not a limitation of a particular architecture, it's a computer limitation in general. An architecture with a physical address of 20 bits will address a total of 1 meg, unless you use external memory mapping hardware (most 8-bit micros of the Eighties could address 64k of memory; anything with more than 64k of RAM+ROM+MMIO needed external hardware to map or page memory — typically generating a whole range of other issues).

The 686 architecture can physically address 64 gigs of memory (there are 36 physical address lines). Logically, because it uses 32-bit registers, you get 4 gigs per task.

PAE is basically an in-CPU scheme for expanding the address space. It's similar in spirit to all those ad-hoc external hardware tricks the 8-bitters used to do, but it's a lot more elegant because the CPU is fully aware of it.

As a historical note, the 8086/88 did this too (in a much more primitive way). There were 20 address lines (20-bit physical addresses, or 1 megabyte), but the CPU only had 16-bit registers. So it used ‘segments’, which addressed the top 16 bits, and ‘offsets’, which were added to segments to form full addresses. Segments and offsets overlap by 12 bits. This is the explanation behind DOS' use of a ‘paragraph’ of 16 bytes (4 bits) in its pathetic memory ‘management’.

Which implies that your example of 0xa0000000 is wrong: you mean segment a000, offset 0000 (a000:0000). Because the least significant 12 bits of the segment coincide with the most significant 12 bits of the address, you're really talking about physical address 0xa0000, or address = segment << 4 + offset. (explanation)

I really didn't want to remember this stuff. Avoiding all the pain and suffering of 8086 CPUs (and DOS) was kind of instrumental to my switching to Linux.


February 28 2008, 19:13:37 UTC 6 years ago

Ah yes, I seem to have go a little confused about what was beign discussed, and you're right with 0xa000, I should have remembered that from my earliest days of tooling around with graphics programming.


February 28 2008, 14:24:35 UTC 6 years ago

It's not a problem with all 32 bit OS'es. Most will happily use over 4GB RAM, if you have it.


February 28 2008, 14:26:48 UTC 6 years ago

in that case, i have been misinformed, and i stand corrected.


February 28 2008, 17:03:56 UTC 6 years ago

Unless it's Windows (32Bit) in which case you have to change the configuration to use more than 3GB for anythign other than the O/S.


February 28 2008, 17:32:18 UTC 6 years ago

Windows is one of the few exceptions, indeed. Horribly engineered piece of crap OS.


February 28 2008, 11:12:38 UTC 6 years ago


February 28 2008, 11:56:41 UTC 6 years ago

Its not a 32-bit limitation. For example, the 32-bit windows server can access more than 4Gb of RAM (If you run the Enterprise Edition or Datacenter) using /PAE as a flag in boot.ini.

IIRC the limitation is to do with addressable space - PAE gives each process a 4GB window on the available memory. I believe linux has PAE support as well.


February 28 2008, 13:22:50 UTC 6 years ago

Linux does have PAE. You need to have that turned on when you compile your kernel or with some distributions they have a special kernel (eg. bigmem on Debian). I have a 32 bit server with 12GB of RAM. The only downside is that a single process can only use 4GB max.


February 28 2008, 14:23:00 UTC 6 years ago

No, it's not an inherent 32 bit OS limitation. It's an implementation limitation. The x86 32 bit architecture allows for 4GB per task, and in modern 686 architectures address a total of 64GB can be used. Any limitation below this is purely in implementation (of motherboard and/or OS).

32 bit Linux will happily address this much memory, if you have it. Often distributions designed for home use will artificially limit this though, since home systems generally do not ship with 64GB RAM. Or even over 4GB RAM. At least not yet. Also, many motherboards do not support the addressing mode required to get above 4GB physical memory (PAE).


February 28 2008, 14:25:24 UTC 6 years ago

Per process, not task, ofc. Would be strange otherwise. ^^


February 28 2008, 15:52:36 UTC 6 years ago

What is the difference between a process and a task, please?


February 28 2008, 17:39:17 UTC 6 years ago

That's a deceptively simple question with a highly complex and technical answer. Short, sweet, simplified and thus not quite correct, a task is something which is presently running, while a process is a chunk of resources (memory, cpu time etc.) that has been set aside and which may or may not be running right now. The correct answer takes up chapters in OS design books, and still make a muddy job of explaining the difference.


February 28 2008, 18:18:14 UTC 6 years ago

I may have a few of the numbers and details off, but this is my understanding of the issue.

Anything which uses 32 bit pointers for memory locations is naturally limited to 2^32 bytes of addressable memory. That's the four gig limit that haunts Windows users. For CPUs earlier than the Pentium-Pro and Athlon that's what you're stuck with. Most processors produced after 1995 have the capability of using Physical Address Extension, or PAE.

PAE allows you to use 36 bits instead, increasing your available memory by a factor of 2^4 or 16. That gives you sixty-four gigabytes to play with, but only code that was compiled with PAE support will be able to do that. Standard x86 code will still use only 32 bit pointers and be limited to four gigabytes.

Linux, FreeBSD, and various other operating systems on the side of good all ship with PAE as a kernel option, but it isn't always enabled by default because there are still some systems which lack PAE support. Applications are generally compiled without PAE so that they will be able to run on non-PAE kernels. This means that each process can only see four gigabytes of memory, but the kernel can map that space anywhere it likes in the sixty-four gigabyte space that it can see. The actual amount of kernel memory is nicely hidden behind a big friendly API and the running processes never need to know the difference. A PAE kernel can neatly manage 64 gigabytes of physical memory and hardware addresses and use the magic of memory mapping to parcel that out in four gigabyte chunks to that processes that it runs and everybody will be happy.

Where things start to Go Horribly Wrong is when you try to load kernel modules which were not compiled with PAE support directly into a PAE kernel. Passing a 36 bit pointer to a function which expects 32 bit pointers is the programming equivalent of Crossing The Streams. Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light. That's pretty much what happens to your entire system.

Fixing that when you have access to the source is usually as simple as rebuilding the kernel and all modules with the right compiler options, but that simply isn't an option for most Windows device drivers. It's especially not an option if you're dealing with code that handles pointers in unsafe or non-portable ways and just _can't_ be convinced to understand PAE. That's why Windows sticks with the 4G limit, with either two or three gigabytes being usable memory for each process and the rest given over to hardware access and other kernely voodoo.

Naturally running a 64 bit operating system will solve this problem. The x86_64 right now uses 40 bits for memory addresses, giving you one thousand and twenty four gigabytes to play with. That catch is that, just like running with PAE enabled, all your kernel modules or device drivers need to be built in x86_64 code. Unfortunately, the 64 bit Windows device drivers are being produced by the same people who can't code reliable PAE-enabled drivers, so good luck with that.

I run into this a lot...


February 28 2008, 18:26:28 UTC 6 years ago

32-bit architectures can only address 4096MB of RAM at any one time (2^32 bytes) natively. On Intel-based 32-bit architectures of a fairly recent vintage, there is an extension in the processor called PAE which requires special OS support, and XP by and large is missing this functionality (Which was a design choice by Microsoft, as other Windows flavors do have PAE-support). On Linux systems, a special kernel is required to take advantage of PAE (On Debian 4, it's the "bigmem" kernel, Debian 3 doesn't have PAE support out of the box; on Fedora/RHEL/CentOS, it's the "PAE" kernel).

Now, while th OS with PAE support can address more than 4GB of RAM, each process (running program image in memory, including all threads) can generally only access 4GB of RAM max, and often times can only address 2-3GB (The other 1-2GB being "reserved"). This has resulted in a big push by many vendors and users to jump to 64-bit (e.g. EM64T on Intel, AMD64 on AMD, or "x86_64" in Linux).

There are ways around the 2-4GB limit in 32-bit programs, but for most people, it's easier to change to 64-bit than re-write all the code (Assuming you have it).

Re: I run into this a lot...


March 5 2008, 21:49:45 UTC 6 years ago

Which was a design marketing choice by Microsoft, as other Windows flavors do have PAE-support

Fixed that for you. :-) They want you to buy the more expensive version.