DragonFly kernel List (threaded) for 2007-01
Re: Re vkernel and all
:A few (dumb) questions, just out of curiosity ...
:When I start a qemu virtual machine with, say, 128 MB of
:RAM, then that memory is allocated to the qemu process in
:a normal way, i.e. it can also be paged to swap.
:If I understand you correctly, then DF's virtual kernels
:work differently: they delegate the allocations to the
:real kernel. Right? I guess that means that the memory
:of user processes running in the vkernel can be paged to
:swap, while the pages of the vkernel (its virtual KVM,
:so to speak) are locked to physical RAM, just like the
:real kernel. Is that correct?
The virtual kernel's 'memory' is just file-backed memory
from the point of view of the real kernel. The virtual kernel
accesses it via mmap(). This means the real kernel is free
to page-out the virtual kernel's 'memory'.
But it isn't a good idea to overallocate your memory, because
the virtual kernel *WILL* try to use all the memory you tell it
has to use.
:What about the cache (VM cache, buffer cache, whatever).
:During normal operation, a kernel tends to use almost all
:free RAM for the cache, i.e. there is almost zero free
:RAM. Do the virtual kernels behave the same? Do they
:even have their own caches?
Virtual kernels behave exactly the same. They do have their
own caches... their own VM page cache, buffer cache, etc.
You can even give a virtual kernel its own swap space (from
the point of the virtual kernel).
A virtual kernel *IS* a real kernel for all intents and
purposes, just one that happens to run as a self contained
In tests I can easily thrash a virtual kernel by running a
large parallel buildworld inside the virtual kernel, and yet
not thrash the real kernel the virtual kernel is running
under. It's a weird sight to see but it is one of the cooler
features... total control over resources. We could even
easily add features to the virtual kernel's drivers to
control disk and network bandwidth.
:I guess what I'm really trying to ask is this: If I
:start 4 vkernels, each with 256 MB RAM, will they
:use 1 GB of real memory, even if only a few small
:processes run inside them?
Pretty much yes. This is primarily going to be due to the
VM page cache. It works the same in the virtual kernel as it
does in a real kernel.
Is it possible to make the virtual kernel free backing store
and be more friendly to the real kernel? Yes, it is, but some
work would have to be done to get the expected results:
* VM system would have to be told to be more aggressive at freeing
* We would have to add a new mcontrol() feature that allows the
virtual kernel to tell the real kernel what pages can be freed,
aka MADV_FREE (MADV_FREE doesn't work on MAP_VPAGETABLE
mmap()'s because their is no way to specify the physical offset).
Then when the virtual kernel does a vm_page_free() it could
use the new call to tell the real kernel to throw away the
contents as well.
:Unfortunately I currently don't have a spare machine to
:install -preview and play with vkernels myself. :-(