|
From: | Jagane Sundar |
Subject: | Re: [Qemu-devel] [patch 6/7] QEMU live block copy |
Date: | Thu, 09 Jun 2011 08:42:17 -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 |
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.See async.c.
Thanks - I will do so.
There is synchronous I/O emulation in block.c for BlockDrivers that don't support .bdrv_read()/.bdrv_write() but only .bdrv_aio_readv()/.bdrv_aio_writev(). The way it works is that it pushes a new I/O context and then issues async I/O. Then it runs a special event loop waiting for that I/O to complete. After the I/O completes it pops the context again.
OK. This is the opposite of what I was thinking of. I was considering the code that emulates Async I/O using multiple threads. It sounds like the goal of this async.c mechanism is more than serializing all synchronous I/O requests, right?
The point of the context is that completions only get called for the current context. Therefore callers of the synchronous I/O functions don't need to worry that the state of the world might change during their "synchronous" operation - only their own I/O operation can complete. If a pending async I/O completes during synchronous I/O emulation, its callback is not invoked until the bottom half (BH) is called after the async context is popped. This guarantees that the synchronous operation and its caller have completed before I/O completion callbacks are invoked for pending async I/O.
OK. This might not be a problem for Livebackup, after all. Livebackup transparently interposes the async I/O offered by the driver. Hence the async.c mechanism is layered neatly above the async_block_driver+livebackup layer and should work correctly. I will take a closer look at this, and check for sanity... Thanks, Jagane
[Prev in Thread] | Current Thread | [Next in Thread] |