[Gllug] 4G Memory Restriction

Alain Williams addw at phcomp.co.uk
Mon Apr 10 10:18:19 UTC 2006


On Mon, Apr 10, 2006 at 11:00:01AM +0100, Steve Nelson wrote:
> Hi all,
> 
> I wanted to check my understanding on a matter before I write some
> documentation on Linux memory management.
> 
> I've currently stated:
> 
> """4GB is the maximum any OS can address in 32-bits.
> 
> However, Linux (and other OS) have strategies to cope with >4GB memory.
> 
> Current Linux 2.4 & 2.6 series, RedHat compiled, kernels on IA-32
> hardware support >4GB memory by default.
> 
> Current Linux 2.4 & 2.6 series, RedHat compiled, "huge memory" kernels
> (kernel-hugemem) on IA-32 support >16GB memory.
> 
> Earlier versions of RedHat's OS had the option of "big memory" kernels
> ( 4GB< kernel-bigmem <16GB) this is no longer the case as the required
> patches are included in the default kernels (both uni &
> multi-processor flavours)."""
> 
> Any inaccuracies here, or is this pretty spot on?  Anything I've missed out?

4GB is the max that can be addressed with 32 bits, however by fiddling with
the address tables you can make use of more than 4GB.
The point is that each process is limited to 4GB, but the kernel can map
that 4GB differently for each process. This happens anyway since you don't
want different processes seeing each others' memory.

So if your applications are several very large memory usage processes, you
can accomodate several of them on a machine with > 4GB memory; however
each process is limited to 4GB.

Note that the kernel uses the top GB of each processes virtual memory, ie
0 to < 3GB is usableby the process >3GB to < 4GB is used by the kernel.

If you process needs > 3GB for it's own use, you need to move to a 64bit machine.

-- 
Alain Williams
Parliament Hill Computers Ltd.
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/

#include <std_disclaimer.h>
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list