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

[Xen-devel] Re: [Devel] Re: [RFC] Virtualization steps

To: Matt Ayres <matta@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [Devel] Re: [RFC] Virtualization steps
From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
Date: Tue, 28 Mar 2006 09:42:41 -0700
Cc: akpm@xxxxxxxx, Nick Piggin <nickpiggin@xxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, sam@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, serue@xxxxxxxxxx, Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>, herbert@xxxxxxxxxxxx, devel@xxxxxxxxxx
Delivery-date: Wed, 29 Mar 2006 13:52:59 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <44295AE8.7010200@xxxxxxxxxxxx> (Matt Ayres's message of "Tue, 28 Mar 2006 10:48:56 -0500")
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <44242A3F.1010307@xxxxx> <44242D4D.40702@xxxxxxxxxxxx> <4428FB90.5000601@xxxxx> <44295AE8.7010200@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
Matt Ayres <matta@xxxxxxxxxxxx> writes:

> I think the Xen guys would disagree with you on this.  Xen claims <3% overhead
> on the XenSource site.
>
> Where did you get these figures from?  What Xen version did you test? What was
> your configuration? Did you have kernel debugging enabled? You can't just post
> numbers without the data to back it up, especially when it conflicts greatly
> with the Xen developers statements.  AFAIK Xen is well on it's way to 
> inclusion
> into the mainstream kernel.

It doesn't matter.  The proof that Xen has more overhead is trivial
Xen does more, and Xen clients don't share resources well.

Nor is this about Xen vs what we are doing.  These are different
non conflicting approaches that operating in completely different
ways and solve a different set of problems.

Xen is about multiple kernels.

The alternative is a supped of chroot.

Eric

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

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