From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49126) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMCH8-0000kE-LQ for qemu-devel@nongnu.org; Mon, 03 Aug 2015 05:43:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZMCH5-0006rE-Ej for qemu-devel@nongnu.org; Mon, 03 Aug 2015 05:43:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMCH5-0006r4-75 for qemu-devel@nongnu.org; Mon, 03 Aug 2015 05:43:15 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id CFB758C1C2 for ; Mon, 3 Aug 2015 09:43:14 +0000 (UTC) Date: Mon, 3 Aug 2015 11:43:08 +0200 From: Marc =?UTF-8?B?TWFyw60=?= Message-ID: <20150803114308.474b332a@markmb_rh> In-Reply-To: <20150803092337.GF22485@redhat.com> References: <20150731174542.44862e3a@markmb_rh> <20150803092337.GF22485@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: "Daniel P. Berrange" Cc: qemu-devel On Mon, 3 Aug 2015 10:23:37 +0100 "Daniel P. Berrange" wrote: > On Fri, Jul 31, 2015 at 05:45:42PM +0200, Marc Mar=C3=AD wrote: > > Hi everyone > >=20 > > I propose improving the current modular driver system for QEMU so it > > can benefit everybody in speed and flexibility. I'm looking for > > other ideas, comments, critics, etc. > >=20 > > - Background - > > In order to speed up QEMU, I'm looking at the high number of > > libraries and dependencies that it loads. I've generated a QEMU > > image that needs 145 shared libraries to start, and there were > > still some options disabled. This is a lot, and this means that it > > is slow. > >=20 > > So I've been looking at actual module system. Yes, QEMU does have a > > module system, but disabled by default. The problem is, the modules > > get loaded always during startup. This means, booting with modules > > enabled is even slower, because loading at runtime is slower that > > letting the linker do all the work at the start. At this point, I > > doubt of the benefits of the actual modular system. > >=20 > > But, if disabling the actual block modules (iscsi, curl, rbd, > > gluster, ssh and dmg) gives 40 ms of speedup, I think is worth an > > effort of improving modules, and modularizing new parts > >=20 > > - Current module flow - > > The current module system is based on shared libraries. Each of > > these libraries has a constructor that registers the BlockDriver > > structure to the global bdrv_drivers list. This list is later > > searched by the type, the protocol, etc. > >=20 > > - Proposals - > > I have in mind two ideas, which are not mutually exclusive: >=20 > [snip] >=20 > > - My comments on my proposals - > > Ideally, I'd like a mixed solution. The user can specify what wants > > to load, but also, when something is not found, it is automatically > > searched. > >=20 > > In both options, the current module system has to be partly > > rewritten, and some of the current drivers with module capability > > might need to be modified to adapt to the new specifications. > >=20 > > And, a part from improving the current modular interface, there are > > a lot of other devices that might benefit from it, not just the > > block devices. > >=20 > > I still haven't looked at the memory footprint of QEMU, but I'm sure > > that the QEMU binary will lose a lot of weight with this addition. >=20 > One think I don't see mentioned is how this impacts on QEMU feature > detection by apps. For example, the recommended approach currnetly > is to launch QEMU with 'qemu-system-BLAH --machine none > -qmp /some/sock' and then query QMP for lists of devices supported, > list of various backends and other features. >=20 > If you're going to suggest a fully modular system, then when doing > QMP feature detection we still need to see the full list of features. > So either that implies all the metadata associated with the modules > remains built-in to QEMU, so QMP can answer this without lodaing the > modules, or the QMP feature detection must imply auto-loading of all > modules that exist. Not everything can be trivially modularized. But, I think that if we are able to get in modules the "very independent" drivers, it will be already a huge improvement. And then, we can think if it's worth the rest of the trouble. Marc