From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37263 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OamJS-0007QO-CH for qemu-devel@nongnu.org; Mon, 19 Jul 2010 05:07:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OamJN-0001Zs-6E for qemu-devel@nongnu.org; Mon, 19 Jul 2010 05:07:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38209) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OamJM-0001Ze-Va for qemu-devel@nongnu.org; Mon, 19 Jul 2010 05:06:57 -0400 Date: Mon, 19 Jul 2010 12:06:54 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) device Message-ID: <20100719090654.GK4689@redhat.com> References: <20100718200942.GL13194@amd.home.annexia.org> <44FD4F00-843D-41C8-B21A-148D16745015@suse.de> <20100719062356.GU4689@redhat.com> <20100719072802.GO13194@amd.home.annexia.org> <20100719073312.GY4689@redhat.com> <20100719074416.GP13194@amd.home.annexia.org> <20100719075533.GC4689@redhat.com> <20100719083411.GR13194@amd.home.annexia.org> <20100719084041.GH4689@redhat.com> <20100719090004.GS13194@amd.home.annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100719090004.GS13194@amd.home.annexia.org> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: Alexander Graf , qemu-devel@nongnu.org On Mon, Jul 19, 2010 at 10:00:04AM +0100, Richard W.M. Jones wrote: > On Mon, Jul 19, 2010 at 11:40:41AM +0300, Gleb Natapov wrote: > > On Mon, Jul 19, 2010 at 09:34:11AM +0100, Richard W.M. Jones wrote: > > > On Mon, Jul 19, 2010 at 10:55:33AM +0300, Gleb Natapov wrote: > > > > Why not put then on cdrom or disk? > > > > > > It simplifies device and mountpoint enumeration not to have a separate > > > disk. It would also mean we couldn't use standard Fedora paths, or > > > we'd have to have bind-mount /bin etc on to the disk mount point, > > > which again complicates things. > > > > > Can't help you here, but if it's doable you can speedup your startup > > time much more then by a second. > > This isn't true. > > The most we could save is 0.8 seconds [time taken to load the 100MB > initrd by the kernel] less the time taken to probe and mount a CD ISO But you do not need all 100MB of application, so with disk approach you load things you need on demand. > [0.2 seconds - measured using guestfish] less the time taken to load > programs from this CD. So the most we could save would be 0.6 > seconds, and in reality it'd be less than this if we actually loaded > and ran any programs from the CD at all. > > My patch saves 1 second, and all the programs are in RAM. > And it will take 100M of a host ram. > > Most users load initrd from a disk not by -initrd option. > > It's unusual, but on my production webserver I use -kernel and -initrd > options explicitly. That's because I want all my VMs to share a > single kernel. > How often you restart them? > virt-install is another program that uses explicit -initrd. > Installation takes a lot of time. Saving 1 second there will not be noticeable. And during lifetime of installed VM initrd will be loaded from its disk. -- Gleb.