Re: [Qemu-devel] Modularizing QEMU RFC

[Daniel P. Berrange]

On Mon, Aug 03, 2015 at 10:24:56AM +0100, Alex Bennée wrote:
> 
> Marc Marí <address@hidden> writes:
> 
> > On Mon, 3 Aug 2015 16:22:34 +0800
> > Fam Zheng <address@hidden> 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.

If you are running a full OS install w/ TCG that 100ms may not be relevant,
but if you are using QEMU w/ KVM as the basis of a more secure environment
for application containers it can be important. eg if it takes 2 secs
from point of exec'ing QEMU to running your app, then 100ms is 5% of
the total time, which is very relevant to consider optimizing. This is the
kind of scenario seen by libguestfs and libvirt-sandbox

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 :|