DragonFly users List (threaded) for 2007-01
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: write news article about virtual kernel
:I'd like to write a quick news article about the virtual kernel support. I
:haven't used it myself yet.
:
:I have a few questions for my article. Feel free to email me off-list by
:Monday morning. (And I will try to publish and promote/submit the article
:by Tuesday morning.)
:
:What existing technology is this comparable too? (Anything else in the BSD
:world?)
The technology is similar to Linux's UML (User Mode Linux).
:Any interesting performance benchmarks yet?
Performance is pretty much as expected. System calls cost around 3uS
and page faults cost a bit less (due to not necessarily having to
be forward to the virtual kernel, since the real kernel maintains the
page tables). Other then that instructions run at full speed.
:How does its performance compare with other technologies?
Very fast booting. I haven't compared the performance with other
technologies but I expect it would depend heavily on the type of
work. Paging or system-call-heavy workloads would suffer the most.
This initial cut does not try to optimize system calls or the VM
system all that much, but it is quite clear to me that optimizing
the VM system at least is very doable. We also haven't optimized
the virtual disk or virtual network subsystems much, other then
implement mailboxes for signals so we could use SIGIO semi-synchronously
without actually having the overhead of a signal handler.
:Any examples of resources or amounts of memory used?
It uses almost precisely the amount of ram you tell it it has to play
with. Real-kernel resources are extremely low. The real kernel has
to maintain a vmspace and pmap for each of the virtual kernel's
processes, but as with all BSDs the pmap's are all throw-away data
and have little impact on real kernel resources.
:How many virtual kernels possible to use on system? (Feel free to describe
:the system.)
Currently the virtual kernel wants to use all the memory you tell it
it has, and that is the main limiting factor. It is possible with only
a small amout of work to make the virtual kernel more memory-friendly,
though, by having it use madvise() to free 'free' pages.
:What is it currently useful for? (I saw posting about some kernel
:development could be done using virtual kernels, as one example.)
:
:If you are using it, what do you use it for?
The most immediate use for us is that it allows us to test
non-hardware-related kernel code in an environment that boots to
a login prompt almost instantly. For example, filesystems,
networking stacks, and mainline kernel code.
Virtual kernels can also be used to provide virtualized systems to
third parties or for compartmentalized security purposes without
having to dedicate an entire machine to the job. Virtual kernels
work far better then jails if security is important since the
interaction with the real kernel is minimal.
:What do you plan to use it for? (Will you replace Xen, jails, anything
:else?)
Each has its place and its use. I don't think virtual kernels can
wholesale replace any of those.
:Where should I point readers for more information on using it?
:
:Where should I point readers for technical development details about it?
The wiki page and the manual page (vkernel) is all we have at the
moment. I really should write up a technical paper on how it was
implemented, because I did add a number of generic but powerful
features to the real kernel to support virtual kernels (mailbox signals,
MAP_VPAGETABLE mmap's, and vmspace_*() system calls to control vmspace
switching).
:When should an end-user start using it? (Is it stable now? Or are
:important new features still in development.)
It should be reasonably stable. The only thing not implemented
are logical descriptor tables (user LDT).
A user should play with it if he has a use and an interest in it, or
just to play around.
:And I am curious ... can a virtual kernel host another virtual kernel?
Yes, though the feature is not well tested and I expect it would be
rather slow.
-Matt
Matthew Dillon
<dillon@backplane.com>
:Feel free to reply off-list.
:
:Thanks!
:
: Jeremy C. Reed
:
:p.s. Now to read the wiki and man page about it ... :)
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]