On Thu, Oct 12, 2000 at 07:19:32PM -0400, Dan Maas wrote:
> 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?
Apparently to catch NULL pointer references with array indices
(int *p = NULL; p[5000])
I agree that is is very wasteful use of precious virtual memory.
> > 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...
Actually most linux boxes do, but with the old term for swapping before
virtual memory (or overlaying in dos terms). They have a cronjob that
expires modules with usage count 0 (or in 2.0 kerneld that did the same)
It is a rather dangerous thing though, module unloading tends to be
one of the most race prone and in addition not too well tested places in
the kernel. I usually recommend to turn it off on any production machine.
In 2.4 with the new fine grained SMP locking is much much more dangerous,
nearly impossible to solve properly.
-Andi
-
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/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:24 EST