Re: [Xen-devel] Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu

[Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>]

Stefan de Konink, le Tue 29 Jul 2008 01:27:24 +0200, a écrit :
> 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?

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

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