From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MiRTr-0007kY-9P for qemu-devel@nongnu.org; Tue, 01 Sep 2009 07:24:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MiRTm-0007kJ-RX for qemu-devel@nongnu.org; Tue, 01 Sep 2009 07:24:55 -0400 Received: from [199.232.76.173] (port=50406 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MiRTm-0007kG-Jt for qemu-devel@nongnu.org; Tue, 01 Sep 2009 07:24:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1025) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MiRTm-0004uL-3P for qemu-devel@nongnu.org; Tue, 01 Sep 2009 07:24:50 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n81BOm6H028408 for ; Tue, 1 Sep 2009 07:24:49 -0400 Message-ID: <4A9D047E.1040208@redhat.com> Date: Tue, 01 Sep 2009 14:24:46 +0300 From: Avi Kivity 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> In-Reply-To: <4A9CFC64.7050603@redhat.com> 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: Kevin Wolf Cc: qemu-devel@nongnu.org On 09/01/2009 01:50 PM, Kevin Wolf wrote: > >> Can't this cause an even/odd pattern where all even-numbered requests >> run first, then all the odd-numbered requests? >> >> (0 goes to disk, 1 depends on it, 2 depends on 1, which isn't allocating >> now, so it goes to disk, 3 depends on 2, ...) >> > I guess it can happen in theory, not sure if it matters in practice. We should check then. > 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. > However, I don't think it's an argument against this patch. What > currently happens isn't much better: Allocate n clusters, free n-1. > Almost as good in producing fragmentation. > The patch introduces complexity so it makes working towards a non-fragmenting solution harder. I'm not saying it could be simplified, it's a side effect of using a state machine design. >> 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? -- error compiling committee.c: too many arguments to function