lkml.org 
[lkml]   [1999]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux address mapping

On Fri, 4 Jun 1999, Bjorn Wesen wrote:

> I'm researching the MMU part of a Linux port, and am possibly slightly
> confused on what the memory map of Linux is supposed to look like.
>
> The i386 version links the kernel to 0xc0000000 (well, plus some 100000
> for some reason). I assume this is to enable process page maps to keep the
> kernels image in the vmem mapping, so that a MMU context switch is not
> required upon systemcalls/irq's (or using weird segment registers like
> fs) (linux 2.0 had the kernel at 0 or ?)

yes. 2.0 did a segmentation trick - but the 2.2 kernel is at 0xc0000000
(unless you change __PAGE_OFFSET for more physical RAM). Thus MMU context
switch is not necessery for entering/leaving the system.

> So as seen from any process, the process itself has its own virtual memory
> between 0 and 0xc0000000 ?

yes - or more exactly: between 0 and PAGE_OFFSET. Right now there is an
additional constraint, 4G-PAGE_OFFSET has to be power-of-2 - because we do
some ugly tricks to support old ISA namespace-using code. This will be
fixed in 2.3.

> However I also understand the kernel can do allocate its own virtual
> memory using vmalloc. Where in the memory space is this placed, and are
> there any particular restrictions/requirements for placing this ? I had
> trouble finding this info while browsing the arch/i386 files. I might just
> be stupid.

it's starting at high_memory+VMALLOC_OFFSET - which is usually 4M above
the physical RAM mappings.

> Another thing I was thinking about, is if the kernel is mapped into every
> process page table, is this done on a page-by-page basis, i.e a 600 kb
> kernel is mapped using for example 600/4 PTE's linearily, but maybe
> processes can share the second level page table for the kernel mapping so
> each process don't need its own kernel PTE map set.

yes, processes share the second kernel page table (the 'page table' in x86
speak). Additionally, on 4M-pages capable CPUs the kernel (and physical
memory) is mapped with 4M mappings - and on 'global pages' capable CPUs
they are also global.

> I wonder if there is an "ideal" MMU for Linux, i.e. one that maximizes
> performance and minimizes the porting work :)

the Linux VM architecture is very clever, you can almost effortlessly port
to whatever sane MMU - without giving up speed. The ideal MMU is
nevertheless something like Sparc64's MMU i guess, but for performance
reasons. The 'simplest' MMU to port to is the one identical to any of the
currently supported MMUs :)

-- mingo


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

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.054 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site