From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMCW9-0002QD-UR for qemu-devel@nongnu.org; Mon, 03 Aug 2015 05:58:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZMCW4-0005N9-V6 for qemu-devel@nongnu.org; Mon, 03 Aug 2015 05:58:49 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:34547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMCW4-0005N3-P5 for qemu-devel@nongnu.org; Mon, 03 Aug 2015 05:58:44 -0400 Received: by wibud3 with SMTP id ud3so128819974wib.1 for ; Mon, 03 Aug 2015 02:58:44 -0700 (PDT) References: <20150731174542.44862e3a@markmb_rh> <20150803030906.GA13938@ad.nay.redhat.com> <20150803095238.663a7bee@markmb_rh> <20150803082234.GA30561@ad.nay.redhat.com> <20150803110147.55ede584@markmb_rh> <87r3nklo5z.fsf@linaro.org> <20150803113618.454a723f@markmb_rh> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <20150803113618.454a723f@markmb_rh> Date: Mon, 03 Aug 2015 10:58:41 +0100 Message-ID: <87pp34lmlq.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] Modularizing QEMU RFC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marc =?utf-8?Q?Mar=C3=AD?= Cc: Fam Zheng , qemu-devel Marc Marí writes: > On Mon, 03 Aug 2015 10:24:56 +0100 > Alex Bennée wrote: > >> >> Marc Marí writes: >> >> > On Mon, 3 Aug 2015 16:22:34 +0800 >> > Fam Zheng 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? >> >> > >> > Some profiling: >> > >> > >> > 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"? >> > > Clear Containers: https://lwn.net/Articles/644675/ > > We are looking for making QEMU more lightweight for the general use > case and also for the container use case. It is a lot better to have > the same tool for both cases, and not start a new one from scratch as > Intel has done. > > This also benefits the general QEMU community, and that's why I'm > having this discussion here. If there's a point where QEMU is still too > slow for containers, but optimizing means breaking, then we will have > to take a step back and change the point of view. > > And making QEMU modular I think is benefitial for everyone. Thanks for the link. If all the less used parts of QEMU where wrapped up into a dynamically linked library (rather than a dynamically loaded module) wouldn't you get the best of both worlds? A fast loading executable which only instantiated the rest if a function from the library was actually called? > > Marc -- Alex Bennée