qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2


From: Avi Kivity
Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
Date: Thu, 05 Aug 2010 05:38:23 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Thunderbird/3.1.1

 On 08/04/2010 11:06 PM, David S. Ahern wrote:

On 08/04/10 11:34, Avi Kivity wrote:

And it's awesome for fast prototyping. Of course, once that fast
becomes dog slow, it's not useful anymore.
For the Nth time, it's only slow with 100MB initrds.
100MB is really not that large for an initrd.

Consider the deployment of stateless nodes - something that
virtualization allows the rapid deployment of. 1 kernel, 1 initrd with
the various binaries to be run. Create nodes as needed by launching a
shell command - be it for more capacity, isolation, etc. Why require an
iso or disk wrapper for a binary blob that is all to be run out of
memory?

It's inefficient. First qemu reads the initrd and stores it in memory (where it is kept while the guest runs in case you migrate or reboot). Then the guest copies it into temporary storage (where we currently have the slowdown). Then the guest decompresses and extracts it to tmpfs (initramfs model). Finally the guest runs init out of initrd, typically using just a part of the 100MB+.

Whereas with a disk image, individual pages are copied to the guest on demand without taking space in qemu. With cache=none, they don't even affect host pagecache.

The -append argument allows boot parameters to be specified at
launch. That is a very powerful and simple design option.

Good point. You still have it with a small initrd that bootstraps a larger image.

Note -append probably works even without -kernel, it's just that the guest isn't tooled to look at it.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




reply via email to

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