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.