From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42595 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ogi6e-0000QI-Rq for qemu-devel@nongnu.org; Wed, 04 Aug 2010 13:50:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ogi6d-0006sO-Mi for qemu-devel@nongnu.org; Wed, 04 Aug 2010 13:50:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53294) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ogi6d-0006sF-Eq for qemu-devel@nongnu.org; Wed, 04 Aug 2010 13:50:19 -0400 Message-ID: <4C59A854.8030000@redhat.com> Date: Wed, 04 Aug 2010 20:50:12 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35? References: <4C590046.2020705@redhat.com> <4C591D48.9080301@redhat.com> <4C592218.3000901@redhat.com> <4C596549.1070109@codemonkey.ws> <20100804130709.GL10499@redhat.com> <4C5967D8.7080707@codemonkey.ws> <20100804133401.GP10499@redhat.com> <4C5970AC.6060105@codemonkey.ws> <4C5995B4.90505@redhat.com> <4C5996F4.6010205@redhat.com> <20100804174601.GH28523@amd.home.annexia.org> In-Reply-To: <20100804174601.GH28523@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, kvm@vger.kernel.org, Gleb Natapov , Gerd Hoffmann On 08/04/2010 08:46 PM, Richard W.M. Jones wrote: > On Wed, Aug 04, 2010 at 07:36:04PM +0300, Avi Kivity wrote: >> This is basically my suggestion to libguestfs: instead of generating >> an initrd, generate a bootable cdrom, and boot from that. The >> result is faster and has a smaller memory footprint. Everyone wins. > We had some discussion of this upstream& decided to do this. It > should save the time it takes for the guest kernel to unpack the > initrd, so maybe another second off boot time, which could bring us > ever closer to the "golden" 5 second boot target. > Great. IMO it's the right thing even if initrd took zero time. > It's not trivial mind you, and won't happen straightaway. Part of it > is that it requires reworking the appliance builder (a matter of just > coding really). The less trivial part is that we have to 'hide' the > CD device throughout the publically available interfaces. Then of > course, a lot of testing. > > I will note that virt-install uses the -initrd interface for > installing guests (large initrds too). And I've talked with a > sysadmin who was using -kernel and -initrd for deploying VM hosting. > In his case he did it so he could centralize kernel distribution / > updates, and have the guests use /dev/vda == filesystem which made > provisioning easy [for him -- I would have used libguestfs ...]. We still plan to improve pio speed. (note a few added seconds to guest install or bootup is not such a drag compared to the hit on an interactive tool like libguestfs). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.