Fwd: Re: [SLUG] Kernel 2.4.19 and 8GB of memory?

From: Ian C. Blenke (icblenke@nks.net)
Date: Mon Nov 25 2002 - 12:52:27 EST


On Monday 25 November 2002 12:04, Ryland Bingham wrote:
> Thanks for the info Ian. I need a little clarification on this point.
>
> > While physical memory can be accessed in 36bits, the process space still
> > remains 32bit. While the kernel can change its process space to access
> > the extra RAM as it needs to, a process cannot - it is effectively
> > limited to 3G (from the 3G/1G split of the 4G addressable 32bit space).
>
> What does this mean? I'm not sure that I understand, what you are
> saying. Does this mean that the processes only have a total of 3GB of
> space? Is there any reason why we would want the kernel to have access
> to 5GB of Memory, that is unavailable to run processes?

The "user mode" of processes only have 3GB of virtual space to access, the
kernel reserves itself 1G of the process' memory map for its own use and is
thus unaccessible.

There are two different ways of looking at memory here. Virtual and physical.
The kernel can access all of physical memory - it presents this memory as
many virtual addresses spaces for each user-mode process. A process can only
access the portion of its own Virtual Memory that it is assigned. Every
process gets its own virtual memory, so you may have multiple processes each
allocating up to ~3G of memory (heap minus shared libraries, stack, etc).

The kernel also uses available RAM for things like disk cache, something that
it can only help to have more of. As soon as the kernel needs to touch
uncached data on a spindle, expect a 1000x slowdown for that operation (thus
IO waiting).

--
- Ian C. Blenke <icblenke@nks.net>

(This message bound by the following: http://www.nks.net/email_disclaimer.html)



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:10:58 EDT