From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MiRnV-0007xu-6h for qemu-devel@nongnu.org; Tue, 01 Sep 2009 07:45:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MiRnP-0007sF-AE for qemu-devel@nongnu.org; Tue, 01 Sep 2009 07:45:11 -0400 Received: from [199.232.76.173] (port=51129 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MiRnO-0007rt-RV for qemu-devel@nongnu.org; Tue, 01 Sep 2009 07:45:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57767) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MiRnO-0001NO-6l for qemu-devel@nongnu.org; Tue, 01 Sep 2009 07:45:06 -0400 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n81Bj4im015674 for ; Tue, 1 Sep 2009 07:45:05 -0400 Message-ID: <4A9D08FE.4070008@redhat.com> Date: Tue, 01 Sep 2009 13:43:58 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qcow2: Order concurrent AIO requests on the same unallocated cluster References: <1251730129-18693-1-git-send-email-kwolf@redhat.com> <4A9CF517.30701@redhat.com> <4A9CFC64.7050603@redhat.com> <4A9D047E.1040208@redhat.com> In-Reply-To: <4A9D047E.1040208@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org Avi Kivity schrieb: > On 09/01/2009 01:50 PM, Kevin Wolf wrote: >> You >> are worried about image fragmentation? I think we could do something >> about it with a cleverer cluster allocation. >> > > Not only image fragmentation - the odd requests will require RMW. How that? The case you're thinking of is that the first and third request are already completed and then the second one starts, right? Assuming that request 2 involves some sectors in the last cluster of 1 and the first one of 3. Then request 2 is written in three phases: The first one overwrites the last sectors of requests 1 (cluster already allocated => no RMW). The second one writes to unallocated, cluster-aligned space (writing complete clusters => no RMW). The third one overwrites the first sectors of request 3 (cluster already allocated => no RMW). >>> Do you have performance numbers? >>> >> No really detailed numbers. Installation time for RHEL on qcow2/virtio >> went down from 34 min to 19 min, though. >> > > That's very impressive. cache=none or cache=wt? This was with cache=none as are most of my ad-hoc tests (with cache=none being the default for RHEL). Kevin