Reducing host memory consumption
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
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:
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'.
apply the devanon patch (available from the
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
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.
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%
This is obviously workload-dependent. Workloads that involve lots of
readonly data, such as code, will benefit more than those that involve
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.
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
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
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