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

[Alexander Graf]

On 04.08.2010, at 18:36, Avi Kivity wrote:

> On 08/04/2010 07:30 PM, Avi Kivity wrote:
>> On 08/04/2010 04:52 PM, Anthony Liguori wrote:
>>>>> 
>>>> This is not like DMA event if done in chunks and chunks can be pretty
>>>> big. The code that dials with copying may temporary unmap some pci
>>>> devices to have more space there.
>>> 
>>> 
>>> That's a bit complicated because SeaBIOS is managing the PCI devices 
>>> whereas the kernel code is running as an option rom.  I don't know the BIOS 
>>> PCI interfaces well so I don't know how doable this is.
>>> 
>>> Maybe we're just being too fancy here.
>>> 
>>> We could rewrite -kernel/-append/-initrd to just generate a floppy image in 
>>> RAM, and just boot from floppy.
>> 
>> How could this work?  the RAM belongs to SeaBIOS immediately after reset, it 
>> would just scribble over it.  Or worse, not scribble on it until some date 
>> in the future.
>> 
>> -kernel data has to find its way to memory after the bios gives control to 
>> some optionrom.  An alternative would be to embed knowledge of -kernel in 
>> seabios, but I don't think it's a good one.
>> 
> 
> Oh, you meant host RAM, not guest RAM.  Disregard.
> 
> This is basically my suggestion to libguestfs: instead of generating an 
> initrd, generate a bootable cdrom, and boot from that.  The result is faster 
> and has a smaller memory footprint.  Everyone wins.

Frankly, I partially agreed to your point when we were talking about 300ms vs. 
2 seconds. Now that we're talking 8 seconds that whole point is moot. We chose 
the wrong interface to transfer kernel+initrd data into the guest.

Now the question is how to fix that. I would veto against anything normally 
guest-OS-visible. By occupying the floppy, you lose a floppy drive in the 
guest. By occupying a disk, you see an unwanted disk in the guest. By taking 
virtio-serial you see an unwanted virtio-serial line in the guest. fw_cfg is 
great because it's a private interface nobody else accesses.

I see two alternatives out of this mess:

1) Speed up string PIO so we're actually fast again.
2) Using a different interface (that could also be DMA fw_cfg - remember, we're 
on a private interface anyways)

Admittedly 1 would also help in more cases than just booting with -kernel and 
-initrd, but if that won't get us to acceptable levels (and yes, 8 seconds for 
100MB is unacceptable) I don't see any way around 2.


Alex