qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Marc Marí" <markmb@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Modularizing QEMU RFC
Date: Mon, 3 Aug 2015 11:01:47 +0200	[thread overview]
Message-ID: <20150803110147.55ede584@markmb_rh> (raw)
In-Reply-To: <20150803082234.GA30561@ad.nay.redhat.com>

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?
> 
> The protocol drivers are modularized for the sake of library
> dependencies, so they should stay that way. However, we can
> "sensibly" combine all non-native format drivers (VMDK, VHDX, ...)
> into a cold-formats.so (if it turns out that loading one big .so is
> much faster than loading separate ones).  But we should leave qcow2
> as a separate one for obvious reasons, or make a hot-formats.so with
> one or two other formats if that makes more sense.
> 
> With that, for the first step, we can lazy load the cold-formats.so
> whenever we need to probe or a non-qcow2 format is involved. Then on
> top of that we can implement what Peter has suggested.
> 

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.

Marc

  reply	other threads:[~2015-08-03  9:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-31 15:45 [Qemu-devel] Modularizing QEMU RFC Marc Marí
2015-08-03  3:09 ` Fam Zheng
2015-08-03  7:51   ` Peter Maydell
2015-08-03  7:52   ` Marc Marí
2015-08-03  8:22     ` Fam Zheng
2015-08-03  9:01       ` Marc Marí [this message]
2015-08-03  9:24         ` Alex Bennée
2015-08-03  9:36           ` Marc Marí
2015-08-03  9:58             ` Alex Bennée
2015-08-03 10:16               ` Daniel P. Berrange
2015-08-03  9:38           ` Daniel P. Berrange
2015-08-03  9:24         ` Fam Zheng
2015-08-03 10:22           ` Marc Marí
2015-08-03 10:54             ` Fam Zheng
2015-08-03  9:20   ` Daniel P. Berrange
2015-08-03  9:52   ` Paolo Bonzini
2015-08-03  9:23 ` Daniel P. Berrange
2015-08-03  9:43   ` Marc Marí

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150803110147.55ede584@markmb_rh \
    --to=markmb@redhat.com \
    --cc=famz@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).