NetBSD Documentation: UVM, the new Virtual Memory system
- What is UVM?
- Who wrote UVM?
- How does UVM handle running out of memory?
- For what does the U stand in UVM?
- How much virtual memory do I have?
- What is ``top down'' memory allocation?
- Which ports use ``top down'' memory allocation?
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. All NetBSD ports use UVM.
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.
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.
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".
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.
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.
All ports use ``top down'' memory allocation except for the hppa port.