Re: [Qemu-devel] Modularizing QEMU RFC

["Marc Marí" <markmb@redhat.com>]

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:
> >
> > A QEMU with this configuration:
> > ./configure --enable-sparse --enable-sdl --enable-gtk --enable-vte \
> >  --enable-curses --enable-vnc --enable-vnc-{jpeg,tls,sasl,png,ws} \
> >  --enable-virtfs --enable-brlapi --enable-curl --enable-fdt \
> >  --enable-bluez --enable-kvm --enable-rdma --enable-uuid
> > --enable-vde \ --enable-linux-aio --enable-cap-ng --enable-attr
> > --enable-vhost-net \ --enable-vhost-scsi --enable-spice
> > --enable-rbd --enable-libiscsi \ --enable-smartcard-nss
> > --enable-guest-agent --enable-libusb \ --enable-usb-redir
> > --enable-lzo --enable-snappy --enable-bzip2 \ --enable-seccomp
> > --enable-coroutine-pool --enable-glusterfs \ --enable-tpm
> > --enable-libssh2 --enable-vhdx --enable-quorum \ --enable-numa
> > --enable-tcmalloc --target-list=x86_64-softmmu
> >
> > Has dependencies on 142 libraries. It takes 60 ms between the run
> > and the jump to the main function, and 80 ms between the run and the
> > first kvm_entry.
> >
> > A QEMU with the same configuration and --enable-modules has
> > dependencies on 125 libraries. It takes 20 ms between the run and
> > the jump to the main function, and 100 ms between the run and the
> > first kvm_entry.
> >
> > The libraries that are not loaded are: libiscsi, libcurl, librbd,
> > librados, ligfapi, libglusterfs, libgfrpc, libgfxdr, libssh2,
> > libcrypt, libidin, libgssapi, liblber, libldap, libboost_thread,
> > libbost_system and libatomic_ops.
> >
> > As I already explained, the current implementation of modules loads
> > the modules at startup always. That's why the QEMU setup takes
> > longer, even though it uses G_MODULE_BIND_LAZY. And that's why I
> > was proposing hotplugging.
> >
> > 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"?
> 
> I don't wish to disparage the idea but certainly in emulation world
> the difference of 100ms or so is neither here nor there.
> 

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.

Marc