From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53106 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ogfqx-0000zx-TK for qemu-devel@nongnu.org; Wed, 04 Aug 2010 11:26:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ogfqw-0000BA-MH for qemu-devel@nongnu.org; Wed, 04 Aug 2010 11:25:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6820) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ogfqw-0000Au-DZ for qemu-devel@nongnu.org; Wed, 04 Aug 2010 11:25:58 -0400 Date: Wed, 4 Aug 2010 18:25:52 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35? Message-ID: <20100804152552.GB10499@redhat.com> References: <4C5847CD.9080107@codemonkey.ws> <4C5848C7.3090806@redhat.com> <4C584982.5000108@codemonkey.ws> <4C584B66.5070404@redhat.com> <4C5854F1.3000905@codemonkey.ws> <4C5858B2.9090801@redhat.com> <4C585F5B.5070502@codemonkey.ws> <4C58635B.7020407@redhat.com> <4C597E6D.1040609@cisco.com> <4C597FCD.8070703@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C597FCD.8070703@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, "Richard W.M. Jones" , Avi Kivity , "David S. Ahern" , kvm@vger.kernel.org On Wed, Aug 04, 2010 at 09:57:17AM -0500, Anthony Liguori wrote: > 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. > The slow down is not 1s any more. String PIO emulation had many bugs that were fixed in 2.6.35. I verified how much time it took to load 100M via fw_cfg interface on older kernel and on 2.6.35. On older kernels on my machine it took ~2-3 second on 2.6.35 it took 26s. Some optimizations that was already committed make it 20s. I have some code prototype that makes it 11s. I don't see how we can get below that, surely not back to ~2-3sec. > 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 > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb.