From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NwcM9-0007Rd-MG
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 10:23:49 -0400
Received: from [140.186.70.92] (port=36176 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NwcM7-0007Pj-Bf
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 10:23:49 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1NwcM1-0000T7-Bh
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 10:23:43 -0400
Received: from mx1.redhat.com ([209.132.183.28]:14424)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1NwcM1-0000Sq-30
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 10:23:41 -0400
Message-ID: <4BB20965.2000200@redhat.com>
Date: Tue, 30 Mar 2010 17:23:33 +0300
From: Avi Kivity <avi@redhat.com>
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>
In-Reply-To: <4BB2059C.8000209@codemonkey.ws>
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: Anthony Liguori <anthony@codemonkey.ws>
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 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?

>
>>
>> If it were just one operation in qcow2, threading would be a big 
>> overkill.  But threading also fixes all of the other format drivers, 
>> and makes working on qcow2 easier.
>>
>
> Yeah, I think the only question is whether to stick threading in the 
> generic block layer or within qcow2.

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).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.