From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37381 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgKyg-0001lg-3I for qemu-devel@nongnu.org; Tue, 03 Aug 2010 13:08:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OgKya-00048f-OA for qemu-devel@nongnu.org; Tue, 03 Aug 2010 13:08:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47324) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgKya-00048Q-GQ for qemu-devel@nongnu.org; Tue, 03 Aug 2010 13:08:28 -0400 Message-ID: <4C584D0A.20803@redhat.com> Date: Tue, 03 Aug 2010 20:08:26 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35? References: <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> <20100803165619.GZ13789@amd.home.annexia.org> In-Reply-To: <20100803165619.GZ13789@amd.home.annexia.org> 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: "Richard W.M. Jones" Cc: qemu-devel@nongnu.org, Gleb Natapov , kvm@vger.kernel.org On 08/03/2010 07:56 PM, Richard W.M. Jones wrote: > On Tue, Aug 03, 2010 at 07:44:49PM +0300, Avi Kivity wrote: >> On 08/03/2010 07:28 PM, Richard W.M. Jones wrote: >>> I have posted a small patch which makes this 650x faster without >>> appreciable complication. >> It doesn't appear to support live migration, or hiding the feature >> for -M older. > AFAICT live migration should still work (even assuming someone live > migrates a domain during early boot, which seems pretty unlikely ...) Live migration is sometimes performed automatically by management tools, which have no idea (nor do they care) what the guest is doing. > Maybe you mean live migration of the dma_* global variables? I can > fix that. Yes. >> It's not a good path to follow. Tomorrow we'll need to load 300MB >> initrds and we'll have to rework this yet again. > Not a very good straw man ... The patch would take ~300ms instead > of ~115ms, versus something like 2 mins 40 seconds with the current > method. > It's still 300ms extra time, with a 900MB footprint. btw, a DMA interface which blocks the guest and/or qemu for 115ms is not something we want to introduce to qemu. dma is hard, doing something simple means it won't work very well. -- error compiling committee.c: too many arguments to function