qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] About making QEMU to LIBs!


From: Xiao Guangrong
Subject: Re: [Qemu-devel] About making QEMU to LIBs!
Date: Thu, 28 Mar 2019 14:45:37 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3



On 3/27/19 5:41 PM, Stefano Garzarella wrote:
Hi Yang, Xiao,
Just adding few things, because I'm currently exploring the QEMU modules
in order to reduce the boot time and the footprint.


Hi Stefan Hajnoczi and Stefano Garzarella,

The work exploring the QEMU modules looks really good. we will
evaluate it.

Hmm... how about make these modules usable out of QEMU, it seems
doable, right? But I'm not sure how much effort we need.


The idea is to create new QEMU modules (like the block/audio/ui
drivers) in order to reduce the dependency of QEMU executable to the
shared libraries that require a lot of time for the initialization, so
we can postpone their initialization only when we will use them.

Using callgrind I'm profiling the loading of dynamic libraries to
understand which part of QEMU should be modularized to speed up the boot
phase when they are not used.

I found that libgnutls, libspice-server and libnuma initialization takes
most of the time. I disabled these libraries (--disable-numa --disable-gnutls
--disable-spice) to understand the maximum speed up and I gained 10 ms
during the boot:
     - qemu_init_end: 50.92 ms
     - qemu_init_end: 40.17 ms (without numa, gnutls and spice)

I would start to modularize spice, the library is used in the spice
drivers (spice-display, spice-chardev, spice-input, etc.) but also in
the QXL emulation.

Maybe we can synchronize our work :)

Great work, Stefano!

Does the benefit come from the fact that your work avoids load some
libraries during exec(), right? So it depends on the size of the
shared library?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]