lkml.org 
[lkml]   [2000]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: large memory support for x86
Chris Swiedler wrote:
>
> > no, x86 virtual memory is 32 bits - segmentation only provides a way to
> > segment this 4GB virtual memory, but cannot extend it. Under Linux there
> > is 3GB virtual memory available to user-space processes.
> >
> > this 3GB virtual memory does not have to be mapped to the same physical
> > pages all the time - and this is nothing new. mmap()/munmap()-ing memory
> > dynamically is one way to 'extend' the amount of physical RAM controlled
> > by a single process. I doubt this would be very economical though.
> >
> > Such big-RAM systems are almost always SMP systems, so eg. a 4-way system
> > can have 4x 3GB processes == 12 GB RAM fully utilized. An 8-way system can
> > utilize up to 24 GB RAM at once, without having to play mmap/munmap
> > 'memory extender' tricks.
>
> Why is it that a user process can't intentionally switch segments?
> Dereferencing a 32-bit address causes the address to be calculated using the
> "current" segment descriptor, right? It seems to me that a process could set
> a new segment selector, in which case a dereference would operate on a whole
> new segment. Is there a reason why processes are limited to a single
> segment?

A segment is just a window mapped on top of virtual memory. A process
can have many segments, but only has one virtual memory mapping. You
cannot use segments to access memory that isn't mapped into the virtual
address space, which is where the 32-bit limit exists. It may be
possible to use the segment not present fault to switch page tables, but
this would be very unportable and would incur alot of extra overhead.

--

Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.082 / U:10.912 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site