|
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.
[Prev in Thread] | Current Thread | [Next in Thread] |