From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41280 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oghr8-0002YO-6x for qemu-devel@nongnu.org; Wed, 04 Aug 2010 13:34:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oghr6-00042k-Sd for qemu-devel@nongnu.org; Wed, 04 Aug 2010 13:34:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31989) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oghr6-00042d-IE for qemu-devel@nongnu.org; Wed, 04 Aug 2010 13:34:16 -0400 Message-ID: <4C59A491.7020904@redhat.com> Date: Wed, 04 Aug 2010 20:34:09 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35? References: <20100803190525.GB16570@redhat.com> <4C586AB9.5040302@codemonkey.ws> <4C586CF9.7030206@redhat.com> <4C588804.5060803@redhat.com> <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> <721C3046-D6A7-47B2-A18C-4E59F2B68797@suse.de> <4C599B45.6030808@redhat.com> <966B1FAB-7E03-4EA6-AC74-767FC400A9CC@suse.de> <4C599FF3.5070208@redhat.com> <3A326B27-9204-4733-A9B6-25EC44291499@suse.de> In-Reply-To: <3A326B27-9204-4733-A9B6-25EC44291499@suse.de> 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: Alexander Graf Cc: Gleb Natapov , kvm@vger.kernel.org, qemu-devel@nongnu.org, "Richard W.M. Jones" , Gerd Hoffmann On 08/04/2010 08:27 PM, Alexander Graf wrote: >> >> Well, it isn't. Two external projects already use it. You can't change it due to the needs to live migrate from older versions. > You can always extend it. You can even break it with a new -M. Yes. But it's a pain to make sure it all works out. We're already suffering from this where we have no choice, why do it where we have a choice? >> It's not wrong in itself, but using it with supersized initrds is wrong. The data is stored in qemu, host pagecache, and the guest, so three copies, it's limited by guest RAM, has to be live migrated. Sure we could optimize it, but it's better to spend our efforts on more mainstream users. > It's only stored twice. The host pagecache copy is gone during the lifetime of the VM. It has still evicted some other pagecache. Footprint is footprint. 300MB to cat some file in a guest. > Migration also doesn't make sense for most -kernel/-initrd use cases. You're just inviting a bug report here. If we add a feature, let's make it work. > And it's awesome for fast prototyping. Of course, once that fast becomes dog slow, it's not useful anymore. For the Nth time, it's only slow with 100MB initrds. > I bet within the time everybody spent on this thread we would have a working and stable DMA fw_cfg interface plus extra spare time for supporting breakage already. The time would have been better spent improving kvm's pio or porting libguestfs to use a cdrom. I'm also hoping to get the point across that adding pv interfaces like crazy is not sustainable. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.