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

[Avi Kivity <avi@redhat.com>]

  On 08/03/2010 05:53 PM, Richard W.M. Jones wrote:
>
>>> Total saving: 115ms.
>> 815 ms by my arithmetic.
> no, not true, 115ms.

If you bypass creating the initrd/cdrom (700 ms) and loading it (115ms) 
you save 815ms.

>> You also save 3*N-2*P memory where N is the size of your initrd and
>> P is the actual amount used by the guest.
> Can you explain this?

(assuming ahead-of-time image generation)

initrd:
   qemu reads image (host pagecache): N
   qemu stores image in RAM: N
   guest copies image to its RAM: N
   guest faults working set (no XIP): P
   total: 3N+P

initramfs:
   qemu reads image (host pagecache): N
   qemu stores image: N
   guest copies image: N
   guest extracts image (XIP): N
   total: 4N

cdrom:
   guest faults working set: P
   kernel faults working set: P
   total: 2P

difference: 3N-P or 4N-2P depending on model


>> Loading a file into memory is plenty fast if you use the standard
>> interfaces.  -kernel -initrd is a specialized interface.
> Why bother with any command line options at all?  After all, they keep
> changing and causing problems for qemu's users ...  Apparently we're
> all doing stuff "wrong", in ways that are never explained by the
> developers.

That's a real problem.  It's hard to explain the intent behind 
something, especially when it's obvious to the author and not so obvious 
to the user.  However making everything do everything under all 
circumstances has its costs.

-kernel and -initrd is a developer's interface intended to make life 
easier for users that use qemu to develop kernels.  It was not intended 
as a high performance DMA engine.  Neither was the firmware 
_configuration_ interface.  That is what virtio and to a lesser extent 
IDE was written to perform.  You'll get much better results from them.

-- 
error compiling committee.c: too many arguments to function