Marc Marí <mar...@redhat.com> writes: > On Mon, 03 Aug 2015 10:24:56 +0100 > Alex Bennée <alex.ben...@linaro.org> wrote: > >> >> Marc Marí <mar...@redhat.com> writes: >> >> > On Mon, 3 Aug 2015 16:22:34 +0800 >> > Fam Zheng <f...@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? >> <snip> >> > >> > Some profiling: >> > <snip> >> > >> > 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
