qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [patch 6/7] QEMU live block copy


From: Jagane Sundar
Subject: Re: [Qemu-devel] [patch 6/7] QEMU live block copy
Date: Wed, 08 Jun 2011 08:10:26 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10

On 6/7/2011 5:15 AM, Stefan Hajnoczi wrote:
On Mon, Jun 6, 2011 at 5:55 PM, Marcelo Tosatti<address@hidden>  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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]