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: [Qemu-devel] [PATCH 0/7] merge some xen bits into qe

To: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu
From: Stefan de Konink <skinkie@xxxxxxxxx>
Date: Tue, 29 Jul 2008 01:27:24 +0200 (CEST)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Gerd Hoffmann <kraxel@xxxxxxxxxx>, Anthony Liguori <anthony@xxxxxxxxxxxxx>
Delivery-date: Mon, 28 Jul 2008 16:27:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080728232255.GD11519@implementation>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 29 Jul 2008, Samuel Thibault wrote:

> Stefan de Konink, le Mon 28 Jul 2008 17:22:39 +0200, a écrit :
> > > This is moving in almost the opposite
> > > direction to Xen upstream is moving: we are moving qemu-dm into its
> > > own tiny domain, so that the qemu code doesn't need to run as a
> > > process in dom0; this has important security and scalability
> > > advantages.
> >
> > I think your userbase prefers the way Red Hat goes. If you do a reality
> > check on the current Python implementation and its memory usage, it is so
> > far from an ESX equivalent that I put my money on any Qemu userspace
> > version.
> >
> > So if you say this new domain will not take at least 128MB extra memory,
> > that could be interesting.
>
> Err...  Currently the default allocated memory is 32MB because there are
> still some bloats, but there is no reason why qemu-dm in its own domain
> should take much more than qemu-dm in dom0.  Currently it should be able
> to fit within 16MB.

And you don't count the 331MB virtual memory the process takes, and every
tapdisk that is created?

But I would love to see the 16MB version...

Stefan


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