From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38159) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUKOx-00036u-3M for qemu-devel@nongnu.org; Wed, 08 Jun 2011 11:10:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QUKOu-0007Ll-7C for qemu-devel@nongnu.org; Wed, 08 Jun 2011 11:10:34 -0400 Received: from qmta01.westchester.pa.hmc1.comcast.net ([76.96.53.8]:59443) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUKOt-0007LQ-TK for qemu-devel@nongnu.org; Wed, 08 Jun 2011 11:10:32 -0400 Message-ID: <4DEF90E2.5080202@sundar.org> Date: Wed, 08 Jun 2011 08:10:26 -0700 From: Jagane Sundar MIME-Version: 1.0 References: <20110606165536.581119615@amt.cnet> <20110606165823.855959321@amt.cnet> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [patch 6/7] QEMU live block copy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: "kwolf@redhat.com" , "dlaor@redhat.com" , "Jes.Sorensen@redhat.com" , Marcelo Tosatti , "qemu-devel@nongnu.org" , "avi@redhat.com" , "jdenemar@redhat.com" On 6/7/2011 5:15 AM, Stefan Hajnoczi wrote: > On Mon, Jun 6, 2011 at 5:55 PM, Marcelo Tosatti wrote: > > I haven't reviewed this whole patch yet, but comments below. > > This patch, like image streaming, may hit deadlocks due to synchronous > I/O emulation. I discovered this problem when working on image > streaming and it should be solved by getting rid of the asynchronous > context concept. The problem is that async I/O emulation will push a > new context, preventing existing requests to complete until the > current context is popped again. If the image format has dependencies > between requests (e.g. QED allocating writes are serialized), then > this leads to deadlock because the new request cannot complete until > the old one does, but the old one needs to wait for the context to be > popped. I think you are not affected by the QED allocating write case > since the source image is only read, not written, by live block copy. > But you might encounter this problem in other places. > Hello Stefan, Can you expand on this some more? I have similar concerns for Livebackup. At the beginning of your paragraph, did you mean 'asynchronous I/O emulation' instead of 'synchronous I/O emulation'? Also, I don't understand the 'stack' construct that you refer to. When you say 'push a new context', are you talking about what happens when a new thread picks up a new async I/O req from the VM, and then proceeds to execute the I/O req? What is this stack that you refer to? Any design documents, code snippets that I can look, other pointers welcome. Thanks, Jagane