Re: large memory support for x86

From: Andi Kleen (
Date: Thu Oct 12 2000 - 18:51:47 EST

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
> -------------
> -------------
> MAPPED FILES (incl. shared libs)
> 0x40000000
> -------------
> HEAP (brk()/malloc())
> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:24 EST