Subject: Re: Sparseness of kernel structures on i386?
To: Chris G Demetriou <Chris_G_Demetriou@auchentoshan.pdl.cs.cmu.edu>
From: Charles M. Hannum <mycroft@gnu.ai.mit.edu>
List: port-i386
Date: 12/08/1996 14:09:58
Chris G Demetriou <Chris_G_Demetriou@auchentoshan.pdl.cs.cmu.edu> writes:
>
> It is not, and apparently cannot be, more than 31. (I asked charles,
> that was his answer, i don't know why it's 31 as opposed to 32, which
> is what i'd expect based on the fact that the kernel currently lives
> in 128MB of virtual space at the top of the i386's virtual address
> range.)
FWIW, the layout of the address space on the i386 looks something
like:
User:
0x00000000 page zero; normally unmapped
0x00001000 text
0xXXXXXXXX data and BSS
0xYYYYYYYY heap
0xZZZZZZZZ stack
0xf7bfe000 end of stack
Kernel:
0xf7bfe000 current process's u-area (no longer used)
0xf7c00000 current process's page table
0xf7fdf000 self-mapping of page table at 0xf7c00000
0xf7fe0000 kernel page table
0xf8000000 heap
0xf8101000 text
0xYYYYYYYY data and BSS
0xZZZZZZZZ heap
0xffc00000 alternate process's page table
0xfffe0000 kernel page table
0xfffff000 self-mapping of page table at 0xffc00000
The `alternate process's page table' is used by the pmap module to
make modifications to another process's page table without reloading
the root page table pointer multiple. It's not clear how much this
actually buys us in performance, but it's only 4MB of va space.
So, you can see where the 4MB goes.