Subject: vm layout changes
To: None <port-arm32@netbsd.org>
From: Chris Gilbert <chris@paradox.demon.co.uk>
List: port-arm32
Date: 08/09/2001 11:10:36
Hi,
Just to forewarn people at some point in the near future (month or so) I'm
planning to rearrange the VM space again, long term this should stop us
having the issues of running out of kvm space as happened on the RiscPC at
the begining of the year.
The current layout is:
* PDE#s VA range usage
* 0->3835 0x0 -> 0xefc00000 user address space
* 3836->3839 0xefc00000-> recursive mapping of PDP (used for
* 0xf0000000 linear mapping of PTPs)
* 3840->3851 0xf0000000-> kernel text address space (constant
* 0xf0c00000 across all pmap's/processes)
* 3852->3855 0xf0c00000-> "alternate" recursive PDP mapping
* 0xf1000000 (for other pmaps)
* 3856->4095 0xf1000000-> KVM and device mappings, constant
* 0x00000000 across all pmaps
(note that not all of the above is guarenteed to be accurate, the bits on the
PDP's maybe wrong)
My plan is to lay it out like:
0x0 -> 0xbfc00000 User address space
0xbfc00000 -> 0xc0000000 PDP space
0xc0000000 -> 0xf0000000 KVM space (controlled by pmap_growkernel function)
0xf0000000 -> 0xf0c00000 kernel text address space
0xf0c00000 -> 0xf1000000 alternate PDP mapping
0xf1000000 -> 0x00000000 VM space for device mapping, arch dependant.
The reason for keeping the kernel where it is, is there's no real need to
move it and because we know that the bootloaders work with it there, and some
of the bootloaders are no longer maintained.
The benefit of this is that we gain the potential to have 768MB of KVM space
(should be more than enough :) We also then have the KVM starting at the
same address and ending at 0xf0000000, unlike currently where the end of kvm
varies depending on what device mappings there are, and what setting is in
vmparam.h Currently the smallest one is shark with 64MB of KVM, prior to
recent changes on riscpc it had the smallest kvm with 48MB which was too
small for the new features in -current.
It should also help with having shared arm32 lkm's, rather than potentially
needing a recompile on each arch. (note that I don't use lkm's so I don't
know if this is currently needed or not)
My main concern with this is the reduction in available user space from near
4GB to only 3 GB :) I'm also not sure where the linker links shared libs in,
and if these changes will effect that.
Order to do all this is:
finish meddling^Wworking on the pmap
implement pmap_growkernel
shift the vm addresses around.
Suggestions? objections? Is this a mad idea? Am I missing something (well
I probably am I'm a developer ;)
This is probably a couple of months away.
Chris