From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-ID: <4C597FCD.8070703@codemonkey.ws> References: <20100803111306.GA21886@amd.home.annexia.org> <20100803113302.GT24773@redhat.com> <20100803121000.GV13789@amd.home.annexia.org> <20100803123714.GU24773@redhat.com> <20100803124808.GW13789@amd.home.annexia.org> <4C58176B.2050306@redhat.com> <20100803140506.GD22211@amd.home.annexia.org> <4C5829E1.60004@redhat.com> <20100803145337.GF22211@amd.home.annexia.org> <4C583F6A.7030600@redhat.com> <20100803162857.GX13789@amd.home.annexia.org> <4C584781.9040609@redhat.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , kvm@vger.kernel.org, "Richard W.M. Jones" , Gleb Natapov , qemu-devel@nongnu.org To: "David S. Ahern" Return-path: Received: from mail-qy0-f181.google.com ([209.85.216.181]:32905 "EHLO mail-qy0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932935Ab0HDO5W (ORCPT ); Wed, 4 Aug 2010 10:57:22 -0400 Received: by qyk7 with SMTP id 7so1803898qyk.19 for ; Wed, 04 Aug 2010 07:57:22 -0700 (PDT) In-Reply-To: <4C597E6D.1040609@cisco.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34016 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgfPL-0005BU-DT for qemu-devel@nongnu.org; Wed, 04 Aug 2010 10:57:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OgfPG-0004F2-Qp for qemu-devel@nongnu.org; Wed, 04 Aug 2010 10:57:27 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:43429) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgfPG-0004Ex-OZ for qemu-devel@nongnu.org; Wed, 04 Aug 2010 10:57:22 -0400 Received: by qwf6 with SMTP id 6so1014322qwf.4 for ; Wed, 04 Aug 2010 07:57:22 -0700 (PDT) Message-ID: <4C597FCD.8070703@codemonkey.ws> Date: Wed, 04 Aug 2010 09:57:17 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35? References: <20100803111306.GA21886@amd.home.annexia.org> <20100803113302.GT24773@redhat.com> <20100803121000.GV13789@amd.home.annexia.org> <20100803123714.GU24773@redhat.com> <20100803124808.GW13789@amd.home.annexia.org> <4C58176B.2050306@redhat.com> <20100803140506.GD22211@amd.home.annexia.org> <4C5829E1.60004@redhat.com> <20100803145337.GF22211@amd.home.annexia.org> <4C583F6A.7030600@redhat.com> <20100803162857.GX13789@amd.home.annexia.org> <4C584781.9040609@redhat.com> <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> In-Reply-To: <4C597E6D.1040609@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "David S. Ahern" Cc: qemu-devel@nongnu.org, Gleb Natapov , Avi Kivity , kvm@vger.kernel.org, "Richard W.M. Jones" 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 >