Re: Re vkernel and all

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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
    user process.

    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
      pages.

    * 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.  :-(
:
:Best regards
:   Oliver

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>