Thanks again, this matches my guesses at how things worked. I've just
never run-up against the 32bit limit so I wasn't sure. I don't have any
individual processes that will be using more than 3GB, but I will have
some that are in the 1.5 to 2GB range.
I'm going to be building my own kernel, because there are a couple
patches regarding SMP that my software vendor tells me I need. The
software needs to explicitly bind processes to individual CPU's and I
guess that the 2.4 does not do this well enough yet.
On Mon, 2002-11-25 at 12:52, Ian C. Blenke wrote:
> 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)
>
>
-- Ryland Bingham Unix/Linux Specialist T3 Technologies, Inc.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:11:01 EDT