Site Home Page
The UML Wiki
UML Community Site
The UML roadmap
What it's good for
Case Studies
Kernel Capabilities
Downloading it
Running it
Skas Mode
Incremental Patches
Test Suite
Host memory use
Building filesystems
User Contributions
Related Links
The HOWTO (html)
The HOWTO (text)
Host file access
Device inputs
Sharing filesystems
Creating filesystems
Resizing filesystems
Virtual Networking
Management Console
Kernel Debugging
UML Honeypots
gprof and gcov
Running X
Diagnosing problems
Installing Slackware
Porting UML
IO memory emulation
UML on 2G/2G hosts
Adding a UML system call
Running nested UMLs
How you can help
Kernel projects
A virtual network
An X session
A login session
A debugging session
Slackware installation
Kernel switches
Slackware README
ALS 2000 paper (html)
ALS 2000 paper (TeX)
ALS 2000 slides
LCA 2001 slides
OLS 2001 paper (html)
OLS 2001 paper (TeX)
ALS 2001 paper (html)
ALS 2001 paper (TeX)
UML security (html)
LCA 2002 (html)
WVU 2002 (html)
Security Roundtable (html)
OLS 2002 slides
LWE 2005 slides
Fun and Games
Kernel Hangman
Disaster of the Month

Reducing host memory consumption

The problem
When you start UML, it will create a file whose size is the same as the UML physical memory size, which is whatever you specified with the 'mem=' switch or its default. Initially, none of that is backed with real host memory, but that changes as it touches its physical memory. Its host memory consumption will asymptotically approach its physical memory limit as it reads data into cache. That consumption will not tend to decrease for two reasons
  • UML, like any other Linux kernel, will keep data in cache as long as there is no pressing need for memory. This makes sense for a native kernel running on hardware since there is no other possible use for the memory. However, for UML, the host quite possibly could make better use of any under-used memory.
  • Even if UML did release a bunch of cache, it has no way of communicating that to the host, which will still see that memory as being dirty, and needing preservation, by swapping it if necessary.

Another problem is the unnecessary duplication of data in host memory. If you have a number, say 'n', of UMLs booted from similar disk images, the data that's the same is present 2 * n times in the host memory, n times in the host page cache, and n times in the UML page caches.

Booting those UMLs from the same image with COW files will reduce the number of copies in the host page cache to 1, but there will still be n copies in the UML page caches, one in each UML. These copies can be eliminated with the use of ubd=mmap, which causes the ubd driver to mmap pages from disk images rather than using read() and write(). This causes UML to share page cache with the host.

In order to see any reduction in host memory use, it is necessary to free the UML phsyical memory pages that were over-mapped by the ubd driver. If these are mapped in from tmpfs or any other filesystem, they won't be freed since filesystems preserve data even when the data isn't mapped in anywhere. So, this is where the host /dev/anon driver comes in. It has the property that when a page is mapped in, and subsequently unmapped, the page will be freed back to the host, and any data that was stored there will be lost. Obviously, this is wrong for a filesystem, but this is exactly what's needed for UML.

To have UML use /dev/anon, you need to do the following:
  • apply the devanon patch (available from the download page) to your host kernel
  • make /dev/anon a character device with major number 1 and minor 10
    mknod /dev/anon c 1 10
    with read-write permissions for everyone (or at least everyone who will be running UML)
    chmod 666 /dev/anon
  • get a UML that supports /dev/anon (2.4.23-2 or later)
  • run it with the 'ubd=mmap' switch
  • make sure that the UML filesystems have 4K (one page) blocksize
NOTE: At this point, 'ubd=mmap' is known to eat filesystems, so don't try this yet with data that you care about. If you use COW files, the backing files are safe since they're opened read-only, but any data that UML has write access to is at risk from 'ubd=mmap'.

Use of the 'ubd=mmap' switch is needed in order to get any memory use benefits from /dev/anon. However, UML will use it regardless of whether the ubd driver is doing mmap. This is almost the same as having it use files in /tmp for its physical memory, except that the UMLs won't be limited to the capacity of /tmp. This makes the host management somewhat easier. Without /dev/anon, you need tmpfs mounted on /tmp for optimal UML performance. With it, you get the same performance without needing to make sure that your tmpfs mount is big enough for the UMLs running on the system.

Memory savings
In my testing, which involves booting a number of instances on a Debian image to a login prompt, the combination of /dev/anon and 'ubd=mmap' results in about a 25% decrease in host memory consumption. This was measured by looking at the decrease in free memory per UML when the host was not under memory pressure. Without 'ubd=mmap', this is ~28M. With 'ubd=mmap', this went down to ~21M. I checked this by counting the number of instances I could boot before the host went into swap. This increased from 16 to 20, again a 25% increase.

This is obviously workload-dependent. Workloads that involve lots of readonly data, such as code, will benefit more than those that involve read-write data.

Performance of 'ubd=mmap'
People commonly ask if switching the ubd driver from using read() and write() (and the data copying they do) to using mmap (and the tlb flushing that it does) will help the performance of a single UML. The answer is that the performance is probably about the same either way. The reason is that mmap is an expensive operation for the CPU. People have measured how large data copies have to be in order to be more expensive than playing games with mmap.

The size that I've seen is about 8K, or two pages on x86. Since UML is doing maps with 1 page granularity, which is in the ballpark, you'd expect the performance to be about the same. My testing, which has mostly been kernel builds, bears this out. The speed is pretty close, to within the error, either way.

Future work
This is leading to more flexibility in managing the memory consumption of UMLs and the host. The next step is to allow the host to add and remove memory from UMLs at run-time, i.e. hot-plug memory.

This will allow a utility on the host to keep track of the memory usage of the UMLs and the host, and shuffle memory between the UMLs and to and from the host in order to implement whatever policy is desired.

I am planning a shipping a sample utility which implements the host-should-not-swap policy. This would keep track of the free memory on the host, and, when it gets low, it would remove memory from an idle UML and release it to the host. When the host has ample memory, it would look for a UML that's under memory pressure and give it some memory.

It is also possible to use this facility to reverse the monotonic increase in UML memory consumption described above. By pulling memory out of a UML until it squeals, you will force it to drop its page cache, resetting its host memory consumption to what it was much earlier in its life. Doing this periodically to all the UMLs on the host will result in their cached data being much more up-to-date, at the expense of some performance loss from old cache data not being available and needing to be reread.

These are probably a decent start for any UML site, and might be sufficient for many, but some may need something different. For example, a UML ISP might have different classes of UMLs on the same host, and would want the expensive UMLs to have preference over the cheap ones for whatever memory is available. UML will provide mechanism, plus an example policy or two, and it will be up to the user community to implement whatever policies are appropriate for host memory management.

Hosted at SourceForge Logo