From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Thibault Subject: Re: Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu Date: Tue, 29 Jul 2008 00:39:11 +0100 Message-ID: <20080728233911.GH11519@implementation> References: <20080728232255.GD11519@implementation> <20080729012539.Q2280-100000@xs2.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <20080729012539.Q2280-100000@xs2.xs4all.nl> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefan de Konink Cc: xen-devel@lists.xensource.com, Gerd Hoffmann , Anthony Liguori List-Id: xen-devel@lists.xenproject.org Stefan de Konink, le Tue 29 Jul 2008 01:27:24 +0200, a =E9crit : > On Tue, 29 Jul 2008, Samuel Thibault wrote: >=20 > > Stefan de Konink, le Mon 28 Jul 2008 17:22:39 +0200, a =E9crit : > > > > This is moving in almost the opposite > > > > direction to Xen upstream is moving: we are moving qemu-dm into i= ts > > > > 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 rea= lity > > > 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 userspac= e > > > version. > > > > > > So if you say this new domain will not take at least 128MB extra me= mory, > > > 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 doma= in > > should take much more than qemu-dm in dom0. Currently it should be a= ble > > to fit within 16MB. >=20 > And you don't count the 331MB virtual memory the process takes, and eve= ry > tapdisk that is created? That depends on what you have configured of course. Virtual memory doesn't account at all, most of it just belongs to the guest. > But I would love to see the 16MB version... Well, just configure the use of stubdom-dm, and to see the free memory (of the allocated 32MB), compile with #define LIBC_VERBOSE uncommented in extras/mini-os/lib/sys.c Samuel