Messages in this thread | | | Date | Fri, 4 Jun 1999 17:22:08 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: 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/
| |