From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMBd5-0000WZ-Rl for qemu-devel@nongnu.org; Mon, 03 Aug 2015 05:01:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZMBd2-0005Cb-Lm for qemu-devel@nongnu.org; Mon, 03 Aug 2015 05:01:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43633) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMBd2-0005Bi-HL for qemu-devel@nongnu.org; Mon, 03 Aug 2015 05:01:52 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 6786A923A8 for ; Mon, 3 Aug 2015 09:01:51 +0000 (UTC) Date: Mon, 3 Aug 2015 11:01:47 +0200 From: Marc =?UTF-8?B?TWFyw60=?= Message-ID: <20150803110147.55ede584@markmb_rh> In-Reply-To: <20150803082234.GA30561@ad.nay.redhat.com> References: <20150731174542.44862e3a@markmb_rh> <20150803030906.GA13938@ad.nay.redhat.com> <20150803095238.663a7bee@markmb_rh> <20150803082234.GA30561@ad.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Modularizing QEMU RFC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: qemu-devel On Mon, 3 Aug 2015 16:22:34 +0800 Fam Zheng wrote: > On Mon, 08/03 09:52, Marc Mar=C3=AD wrote: > > So any other ideas to reduce the library overhead are appreciated. >=20 > 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? >=20 > 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. >=20 > 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. >=20 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=3Dx86_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