Re: [Qemu-devel] Modularizing QEMU RFC

[Alex Bennée]

Marc Marí <address@hidden> writes:

> On Mon, 03 Aug 2015 10:24:56 +0100
> Alex Bennée <address@hidden> wrote:
>
>> 
>> Marc Marí <address@hidden> writes:
>> 
>> > On Mon, 3 Aug 2015 16:22:34 +0800
>> > Fam Zheng <address@hidden> 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