From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38787 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgIdS-0003KE-9z for qemu-devel@nongnu.org; Tue, 03 Aug 2010 10:38:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OgIdQ-00039n-Ee for qemu-devel@nongnu.org; Tue, 03 Aug 2010 10:38:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43632) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgIdQ-00039X-5Q for qemu-devel@nongnu.org; Tue, 03 Aug 2010 10:38:28 -0400 Message-ID: <4C5829E1.60004@redhat.com> Date: Tue, 03 Aug 2010 17:38:25 +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> In-Reply-To: <20100803140506.GD22211@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 05:05 PM, Richard W.M. Jones wrote: > On Tue, Aug 03, 2010 at 04:19:39PM +0300, Avi Kivity wrote: >> On 08/03/2010 03:48 PM, Richard W.M. Jones wrote: >>> Thanks for the explanation. I'll repost my "DMA"-like fw-cfg patch >>> once I've rebased it and done some more testing. This huge regression >>> for a common operation (implementing -initrd) needs to be solved >>> without using inb/rep ins. >> Adding more interfaces is easy but a problem in the long term. >> We'll optimize it as much as we can. Meanwhile, why are you loading >> huge initrds? Use a cdrom instead (it will also be faster since the >> guest doesn't need to unpack it). > Because it involves rewriting the entire appliance building process, > and we don't necessarily know if it'll be faster after we've done > that. > > Look: currently we create the initrd on the fly in 700ms. We've no > reason to believe that creating a CD-ROM on the fly wouldn't take > around the same time. After all, both processes involve reading all > the host files from disk and writing a temporary file. The time will only continue to grow as you add features and as the distro bloats naturally. Much better to create it once and only update it if some dependent file changes (basically the current on-the-fly code + save a list of file timestamps). Alternatively, pass through the host filesystem. > You have to create these things on the fly, because we don't actually > ship an appliance to end users, just a tiny (< 1 MB) skeleton. You > can't ship a massive statically linked appliance to end users because > it's just unmanageable (think: security; updates; bandwidth). Shipping it is indeed out of the question. But on-the-fly creation is not the only alternative. > Loading the initrd currently takes 115ms (or could do, if a sensible > 50 line patch was permitted). > > So the only possible saving would be the 115ms load time of the > initrd. In theory the CD-ROM device could be detected in 0 time. > > Total saving: 115ms. 815 ms by my arithmetic. You also save 3*N-2*P memory where N is the size of your initrd and P is the actual amount used by the guest. > But will it be any faster, since after spending 115ms, everything runs > from memory, versus being loaded from the CD? > > Let's face the fact that qemu has suffered from an enormous > regression. From some hundreds of milliseconds up to over a minute, > in the space of 6 months of development. It wasn't qemu, but kvm. And it didn't take six months, just a few commits. Those aren't going back, they're a lot more important than some libguestfs problem which shouldn't have been coded differently in the first place. > For a very simple operation: > loading a file into memory. Loading a file into memory is plenty fast if you use the standard interfaces. -kernel -initrd is a specialized interface. -- error compiling committee.c: too many arguments to function