From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Nwcui-0006t1-BR
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 10:59:32 -0400
Received: from [140.186.70.92] (port=59699 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Nwcuh-0006s5-6a
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 10:59:32 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1Nwcuf-00066S-GE
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 10:59:31 -0400
Received: from mail-pv0-f173.google.com ([74.125.83.173]:39132)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1Nwcuf-00066O-Bw
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 10:59:29 -0400
Received: by pvc21 with SMTP id 21so75629pvc.4
	for <qemu-devel@nongnu.org>; Tue, 30 Mar 2010 07:59:28 -0700 (PDT)
Message-ID: <4BB211CC.4000302@codemonkey.ws>
Date: Tue, 30 Mar 2010 09:59:24 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH -V3 09/32] virtio-9p: Implement P9_TWRITE/
	Thread model in QEMU
References: <1269535420-31206-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>	<1269535420-31206-10-git-send-email-aneesh.kumar@linux.vnet.ibm.com>	<4BB04A59.1040204@linux.vnet.ibm.com>	<4BB0C09D.7090204@linux.vnet.ibm.com>
	<4BB10E30.70908@redhat.com>	<4BB110B3.8040300@linux.vnet.ibm.com>
	<4BB1136B.6050506@redhat.com>	<4BB11A48.4060805@linux.vnet.ibm.com>
	<4BB1D143.5040308@redhat.com>	<4BB1F915.6020800@linux.vnet.ibm.com>
	<4BB1FC83.6000202@redhat.com>	<4BB202A5.8020105@linux.vnet.ibm.com>
	<4BB20496.3080102@redhat.com> <4BB2059C.8000209@codemonkey.ws>
	<4BB20965.2000200@redhat.com>
In-Reply-To: <4BB20965.2000200@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: ericvh@gmail.com, Kevin Wolf <kwolf@redhat.com>, jvrao <jvrao@linux.vnet.ibm.com>, "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>, qemu-devel@nongnu.org

On 03/30/2010 09:23 AM, Avi Kivity wrote:
> On 03/30/2010 05:07 PM, Anthony Liguori wrote:
>> On 03/30/2010 09:03 AM, Avi Kivity wrote:
>>>>
>>>> So it looks like we really only have one operation 
>>>> (qcow2_alloc_cluster_link_l2) that blocks.  Do we really think that 
>>>> it's sufficiently difficult to make this function asynchronous that 
>>>> it justifies threading the block layer?
>>>
>>> There are also tons of bdrv_pread()s and bdrv_pwrite()s.  Isn't 
>>> growing some of the tables synchronous? how about creating a snapshot?
>>
>> Eh, that ruins my whole argument.
>
>
> But we can keep on arguing regardless, yes?

Of course :-)

> Both.  My plan is:
>
> (1) some generic infrastructure
> (2) kit that turns a synchronous block format driver into an 
> asynchronous one using (1), limited to one outstanding request
> (3) adaptations to qcow2 using (1) to make it fully asynchronous, 
> capable of multiple outstanding requests (except when it issues a sync 
> request)
>
> I've mostly done (1) and am contemplating (2).

Sounds reasonable.

Regards,

Anthony Liguori