|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35? |
Date: | Wed, 04 Aug 2010 09:57:17 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 |
On 08/04/2010 09:51 AM, David S. Ahern wrote:
On 08/03/10 12:43, Avi Kivity wrote:libguestfs does not depend on an x86 architectural feature. qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We should discourage people from depending on this interface for production use.That is a feature of qemu - and an important one to me as well. Why should it be discouraged? You end up at the same place -- a running kernel and in-ram filesystem; why require going through a bootloader just because the hardware case needs it?
It's smoke and mirrors. We're still providing a boot loader it's just a little tiny one that we've written soley for this purpose.
And it works fine for production use. The question is whether we ought to be aggressively optimizing it for large initrd sizes. To be honest, after a lot of discussion of possibilities, I've come to the conclusion that it's just not worth it.
There are better ways like using string I/O and optimizing the PIO path in the kernel. That should cut down the 1s slow down with a 100MB initrd by a bit. But honestly, shaving a couple hundred ms further off the initrd load is just not worth it using the current model.
If this is important to someone, we ought to look at refactoring the loader completely to be disk based which is a higher performance interface.
Regards, Anthony Liguori
David
[Prev in Thread] | Current Thread | [Next in Thread] |