[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [GIT PULL] Xen APIC hooks (with io_apic_ops)



George Dunlap wrote:
As a simple example, take scheduling.  I'm about to re-write the Xen
scheduler, and in the process I took a good look at the scheduler you
wrote.  I think it's got a lot of really good ideas, which I plan to
steal. :-)  However, I'm going to have to make some key changes in
order for it to function well as a hypervisor scheduler.  If KVM is
used on a production server with 20 or 30 multi-vcpu VMs, I predict
the current scheduler will do very poorly, because it wasn't designed
with VMs in mind, but with processes.  Making changes so that VMs run
better will fundamentally make things that make processes run less
well.

The Linux scheduler already supports multiple scheduling classes. If we find that none of them will fit our needs, we'll propose a new one. There are also multiple I/O schedulers, multiple allocators (perhaps a bad example), and multiple filesystems.

When the need can be demonstrated to be real, and the implementation can be clean, Linux can usually be adapted.

I think the Xen design has merit if it can truly make dom0 a guest -- that is, if it can survive dom0 failure. Until then, you're just taking a large interdependent codebase and splitting it at some random point, but you don't get any stability or security in return. It will also be interesting to see how far Xen can get along without real memory management (overcommit).

The whole Xen design is messed up really: you have taken off bits of
the Linux kernel you found interesting, turned them into a
micro-kernel in essence and renamed it to 'Xen'.

That's how Xen started, and that's really the beauty of open-source.
(After all, KVM has stolen some ideas from the Xen shadow code.)  But
since then, basically all of the code has been replaced with
Xen-written code.  I think if you did an SCO-style audit comparing
Linux and Xen 3.4, you'd find a lot less in common than you think.

A lot of the arch code is derived from Linux.

Xen isnt actually useful _at all_ without Linux/DOM0. Without Dom0
Xen is slow and native hardware support within Xen is virtually
non-existent, as you point out above.

And qemu-kvm isn't useful _at_all_ without Linux either; and Linux-KVM
isn't useful _at_all_ without qemu.  Your point?

kvm is actually being used by other userspaces.

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.