WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [GIT PULL] Xen APIC hooks (with io_apic_ops)
From: Avi Kivity <avi@xxxxxxxxxx>
Date: Tue, 26 May 2009 21:26:27 +0300
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 26 May 2009 11:28:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <de76405a0905260546k56bc866bx1658ec13f65e3eec@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1242170724-13349-1-git-send-email-jeremy@xxxxxxxx> <20090519123548.GA26439@xxxxxxx> <4A14447E.9060607@xxxxxxxx> <20090525041057.GD9396@xxxxxxx> <de76405a0905260546k56bc866bx1658ec13f65e3eec@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
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

<Prev in Thread] Current Thread [Next in Thread>