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: Wed, 04 Aug 2010 20:14:27 +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 08:01 PM, Alexander Graf wrote:


2) Using a different interface (that could also be DMA fw_cfg - remember, we're 
on a private interface anyways)
A guest/host interface is not private.
fw_cfg is as private as it gets with host/guest interfaces. It's about as close 
as CPU specific MSRs or SMC chips.


Well, it isn't. Two external projects already use it. You can't change it due to the needs to live migrate from older versions.

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.
3) don't use -kernel for 100MB or more.  It's not the right tool.
Why not? You're the one always ranting about caring about users. Now you get at 
least 3 users from the Qemu development community actually using a feature and 
you just claim it's wrong? Please, we've added way more useless features for 
worse reasons.


It's not wrong in itself, but using it with supersized initrds is wrong. The data is stored in qemu, host pagecache, and the guest, so three copies, it's limited by guest RAM, has to be live migrated. Sure we could optimize it, but it's better to spend our efforts on more mainstream users.

If you want to pull large amounts of data into the guest efficiently, use virtio-blk. That's what it's for.

--
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]