The memory map of a user process on x86 looks like this:
-------------
KERNEL (always present here)
0xC0000000
-------------
0xBFFFFFFF
STACK
-------------
MAPPED FILES (incl. shared libs)
0x40000000
-------------
HEAP (brk()/malloc())
EXECUTABLE CODE
0x08048000
-------------
Try examining /proc/*/maps, and also watch your programs call brk() using
strace; you'll see all this in action...
> So why does the process space start at such a high virtual
> address (why not closer to 0x00000000)? Seems we're wasting ~128 megs of
> RAM. Not a huge amount compared to 4G, but signifigant.
I don't know; anyone care to comment?
> Another question: how (and where in the code) do we translate virtual
> user-addresses to physical addresses?
In hardware, with the TLB and, if the TLB misses, then page tables.
> Does the MMU do it, or does it call a
> kernel handler function?
Only when an attempt is made to access an unmapped or protected page; then
you get an interrupt (page fault), which the kernel code handles.
> Why is the kernel allowed to reference physical
> addresses, while user processes go through the translation step?
Not even the kernel accesses physical memory directly. It can, however,
choose to map the physical memory into its own address space contiguously.
Linux puts it at 0xC0000000 and up. (question for the gurus- what happens on
machines with >1GB of RAM?)
> Can kernel
> pages be swapped out / faulted in just like user process pages?
Linux does not swap kernel memory; the kernel is so small it's not worth the
trouble (are there other reasons?). e.g. My Linux boxes run 1-2MB of kernel
code; my NT machine is running >6MB at the moment...
Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
