On Tue, May 28, 2019 at 07:21:38PM +0000, Montes, Julio wrote:
On Tue, 2019-05-28 at 12:10 -0700, Maran Wilson wrote:
On 5/28/2019 11:54 AM, Whaley, Graham wrote:
-----Original Message----- From: Dr. David Alan Gilbert [mailto:dgilbert@redhat.com] Sent: Tuesday, May 28, 2019 7:40 PM To: Montes, Julio <julio.montes@intel.com>; pbonzini@redhat.com Cc: kata-dev@lists.katacontainers.io Subject: Re: [kata-dev] QEMU 4 and QEMU-lite
* Montes, Julio (julio.montes@intel.com) wrote:
On Tue, 2019-05-28 at 18:19 +0100, Dr. David Alan Gilbert wrote:
* Montes, Julio (julio.montes@intel.com) wrote: > Hi kata-folks > > One of the topics in today's agent was QEMU 4 and the work > that we > are doing to support it in Kata Containers. > I ran the boot time and memory footprint metrics in my > workstation > to compare QEMU 4 vs QEMU-lite (2.11). > Here the results. > > Feel free to comment and raise your concerns about QEMU 4.
So that looks pretty nice for QEMU 4; at least as fast and in the noise on the memory usage?
yeah - IMO QEMU 4 has a good performance and new features, it's a good hypervisor for Kata Containers.
Great! Please keep running these tests to make sure we don't regress in future versions (especially on our soft-freezes etc so we can spot them before the next release.
We do have a 'metrics CI' running on Kata, that in theory would detect any major (roughly +/- 5%) shifts - but, that would only happen when Kata updates the version of Qemu it is tracking... And, yes, we will almost definitely have to tweak that CI to account for the new numbers when we land The qemu4 PR ...
Just curious about whether you are providing the uncompressed kernel image in these Qemu 4 tests or not. Qemu 4.0 supports booting the uncompressed kernel binary in order to reduce boot time (if the kernel
\o/ interesting I will try, thanks.
As Maran, I'm also curious about a comparison with the new QEMU 4.0 feature to boot uncompressed kernel binary. Here you can find some useful information (I hope :)): https://gist.github.com/stefano-garzarella/7b7e17e75add20abd1c42fb496cc6504 Thanks, Stefano