Subject: new virtual memory system available: UVM
To: None <current-users@NetBSD.ORG>
From: matthew green <>
List: current-users
Date: 02/07/1998 11:52:54
hi folks.

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 <> 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
	  pageout speeds.

	- 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
configuration file.   

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.


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!