From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53561 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgKbo-0007AJ-Vl for qemu-devel@nongnu.org; Tue, 03 Aug 2010 12:45:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OgKbj-0000K7-UL for qemu-devel@nongnu.org; Tue, 03 Aug 2010 12:44:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2713) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgKbj-0000K1-Ne for qemu-devel@nongnu.org; Tue, 03 Aug 2010 12:44:51 -0400 Message-ID: <4C584781.9040609@redhat.com> Date: Tue, 03 Aug 2010 19:44:49 +0300 From: Avi Kivity 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> In-Reply-To: <20100803162857.GX13789@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:28 PM, Richard W.M. Jones wrote: > On Tue, Aug 03, 2010 at 07:10:18PM +0300, Avi Kivity wrote: >> -kernel and -initrd is a developer's interface intended to make life >> easier for users that use qemu to develop kernels. It was not >> intended as a high performance DMA engine. Neither was the firmware >> _configuration_ interface. That is what virtio and to a lesser >> extent IDE was written to perform. You'll get much better results >> from them. > Firmware configuration replaced something which was already working > really fast -- preloading the images into memory -- with something > which worked slower, and has just recently got _way_ more slow. > > This is a regression. Plain and simple. It's only a regression if there was any intent at making this a performant interface. Otherwise any change an be interpreted as a regression. Even "binary doesn't hash to exact same signature" is a regression. > 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. 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. Meanwhile the kernel and virtio support demand loading of any image size you'd want to use. -- error compiling committee.c: too many arguments to function