Skip to main content.
Google custom search

NetBSD Documentation: UVM, the new Virtual Memory system

Other related links

UVM FAQs


UVM FAQs

What is UVM? (top)

UVM is a complete rewrite of the NetBSD virtual memory system, and has proven to be a much better performer than the Mach VM system. UVM also supports advanced features such as page loanout, and is being used in the development of a unified buffer and page cache for NetBSD.

Who wrote UVM? (top)

Chuck Cranor designed and implemented UVM, Matthew Green handled integration issues and wrote the swap subsystem, Chuck Silvers wrote the anonymous memory object pager (which added support for shared memory), and various other developers have converted the appropriate ports across. Andrew Brown modified UVM to be able to do top down memory management.

How does UVM handle running out of memory? (top)

UVM uses lazy allocation. This means programs can overallocate virtual memory. When UVM detects an out of VM completely condition and a lazy allocated bit of memory is accessed, the offending process will be KILLed and the system will continue. There is also a small buffer of reserve pages only for use by the paging system, which allows the pagedaemon to run comfortably when there is otherwise no free ram. Most of this work was done by Chuck Silvers.

Which ports use UVM? (top)

UVM is not available in the 1.3.X distributions, but is used on all ports for 1.4 and later.

For what does the U stand in UVM? (top)

UVM used to be part of another project worked on by Chuck Cranor that started with the letter "U" (for "universal")... however, that project mutated into just UVM... so the "U" doesn't really stand for anything anymore: "UVM" is just a name that is different from (but close to) "vm".

How much virtual memory do I have? (top)

In UVM, your total virtual memory is equal to the size of your physical RAM (minus kernel overhead) plus the size of each swap partition. In other words, physical memory doesn't have to be backed by a paging device.

What is ``top down'' memory allocation? (top)

This rearranges mmap(2)'ed memory allocations that don't request a specific address such that they start directly below the stack and work from the top down, instead of from the middle upwards. By doing this, the area of space reserved for heap growth and the area of space reserved for mmap(2)'ed allocations are merged, meaning that the heap can grow larger, or a process can mmap more or larger objects. The kernel still uses the traditional ``bottom up'' scheme for its internal memory management.

Which ports use ``top down'' memory allocation? (top)

The top down memory allocation scheme is currently offered as kernel option on the i386 port, and the PowerPC ports: bebox, macppc, mvmeppc, ofppc, pmppc, prep, and sandpoint. It is expected that most ports will eventually transition to using top down unconditionally at some point. Refer to the options(4) man page for more information.