Re: [Qemu-devel] Modularizing QEMU RFC

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Aug 03, 2015 at 10:58:41AM +0100, Alex Bennée wrote:
> 
> Marc Marí <markmb@redhat.com> writes:
> 
> > On Mon, 03 Aug 2015 10:24:56 +0100
> > Alex Bennée <alex.bennee@linaro.org> wrote:
> >
> >> 
> >> Marc Marí <markmb@redhat.com> writes:
> >> 
> >> > On Mon, 3 Aug 2015 16:22:34 +0800
> >> > Fam Zheng <famz@redhat.com> wrote:
> >> >
> >> >> On Mon, 08/03 09:52, Marc Marí wrote:
> >> >> > So any other ideas to reduce the library overhead are
> >> >> > appreciated.
> >> >> 
> >> >> It would be interesting to see your profiling on the library
> >> >> loading overhead. For example, how much does it help to reduce the
> >> >> library size, and how much does it help to reduce the # of
> >> >> libraries?
> >> <snip>
> >> >
> >> > Some profiling:
> >> >
> <snip>
> >> >
> >> > I don't know if loading one big library is more efficent than a lot
> >> > of small ones, but it would make sense.
> >> 
> >> What's the actual use-case here where start-up latency is so
> >> important? If it is an ephemeral cloudy thing then you might just
> >> have a base QEMU with VIRT drivers and one big .so call "the-rest.so"?
> >> 
> >
> > Clear Containers: https://lwn.net/Articles/644675/
> >
> > We are looking for making QEMU more lightweight for the general use
> > case and also for the container use case. It is a lot better to have
> > the same tool for both cases, and not start a new one from scratch as
> > Intel has done.
> >
> > This also benefits the general QEMU community, and that's why I'm
> > having this discussion here. If there's a point where QEMU is still too
> > slow for containers, but optimizing means breaking, then we will have
> > to take a step back and change the point of view.
> >
> > And making QEMU modular I think is benefitial for everyone.
> 
> Thanks for the link.
> 
> If all the less used parts of QEMU where wrapped up into a dynamically
> linked library (rather than a dynamically loaded module) wouldn't you
> get the best of both worlds? A fast loading executable which only
> instantiated the rest if a function from the library was actually called?

The problem lies with defining what "the less used parts" actually
are. You'll end up building something which suits one case, at the
expense of another case, because everyone will have a different
perception on what the less used parts are. A large portion of the
QEMU userbase probably don't care about RBD block driver whatsoever,
but another significant portion probably use it for all their storage
needs and don't ever use any other block driver. A general purpose
module loading system avoids having to favour one particular usage
scenario at the expense of others.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|