All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.