Subject: new virtual memory system available: UVM
To: None <netbsd-announce@NetBSD.ORG>
From: matthew green <firstname.lastname@example.org>
Date: 02/07/1998 11:52:54
recently, i committed UVM (the new virtual memory subsystem) to the
master NetBSD source tree. this is a major change.
UVM was written by Chuck Cranor <email@example.com> over the
past two or so years (with a bit of help more recently from myself
and a few other people). UVM is a complete rewrite of the VM system
inspired by Chuck's research, the old Mach VM code, the SunOS VM
system (as described in R. Gingell, et al.'s papers), John Dyson's
work on the FreeBSD VM, and other random sources.
the selection of which VM system to compile into the kernel is
currently an option that can be configured in the kernel's config
file. currently UVM is only supported on the sparc and i386 ports.
more will come later, when other ports are ready.
interesting aspects of UVM include:
- complete replacement of anonymous memory handing. the old
Mach code uses "shadow and copy object chains" which lead to
the pesky "swap memory leak" problem which can only be fixed
with complex vm_object collapse code which has proved
troublesome to us in its own right. UVM uses a variant of
the amap/anon ideas presented in the SunOS VM papers to
manage anonymous memory to entirely avoid vm_object chains.
this also allows us to dispose of the tricky vm_mmap() layer
with all its vm_object related code.
- Mach VM data structure locking scheme updated for new data
structures and fine grained simple_lock'ing structure restored.
(might be useful for SMP?)
- new pager interface eliminates the need for PG_FICTITIOUS
pages and gives the pager more control over its pages.
- new anonymous swap clustering pageout code allows on the fly
reassignment of drum resources thus allowing large clusters
to always be build. this vastly improves anonymous memory
- elimination of the Mach vm_object cache. object persistence
is now fully under the control of the object being mapped.
this allows vnode vm_objects to persist without having to
hold an active VREF on the underlying vnode. a persisting
vm_object will live as long as its backing vnode is not
- page loanout is supported: this enables the VM system
to safely loan out its memory to other kernel subsystems
(e.g. the mbuf system). this will eventually allow pages
of data to move between user space and the I/O system (or
other processes) without the need for data copies.
- new i386 pmap: it is a mix of new ideas, the old pmap, the
FreeBSD i386 pmap, and the Mach pmap. it gets the user
PTEs out of user space (no more "fault the PTP" hack code
in trap.c), removes a couple of deadlock problems, has the
FreeBSD pmap_growkernel interface (to get rid of those
annoying "ptdi" panics once and for all), etc...
- vm_map_entry fragmentation improved by dumping the
buffer_map, and reworking the way memory is wired.
the statically allocated pool of vm_map_entry structures for
the kernel will eventually be done away with to rid us
of the "out of map entrys" panic [work in progress, but
not finished yet]
- new unified handling of non-contig physical memory with
MACHINE_NEW_NONCONTIG (aka MNN). machines with contig
physical memory can easily use MACHINE_NEW_NONCONTIG with
no extra costs.
- redundant VM calls eliminated in the fork/exec/exit path,
thus reducing kernel overhead.
- sysctl based VM system info: allows you to get the status of
the VM system without having to be setgid kmem.
- the ability to stop swapping on a device/file [work in
progress, but not finished yet].
- improved source code documentation
note that the issue of merging the VM and buffer cache has not been
addressed in UVM. the plan is to defer that issue until after the
UVM has settled.
UVM can be enabled by the `options UVM' option in your kernel
NOTE: many of the userland libkvm programs (e.g. "ps") do not yet work
with UVM. but most other things work just as normal (and some
better/faster :-). this will be worked on shortly and utilities will
be given the ability to compile to work for UVM kernels, rather than
old VM kernels.
please report any problems that you find via send-pr and we will
try to take care of them as soon as possible.
WARNING WARNING WARNING
UVM is a "work in progress" and thus you use it at your own risk at
this stage. while we have been using UVM for several months on our
development machines, there are almost certainly still bugs that are
yet to be found, so be careful.
also, note that the internal interfaces of UVM are not set in stone.
as new ideas come up the internals of UVM may have to be adjusted to
address them (e.g. the pager interface is likely to change again at
some point in the future).
thanks to chuck for providing us with UVM!