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

[Avi Kivity <avi@redhat.com>]

  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.