[Top][All Lists]

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

Re: [Qemu-block] interesting blog post about asynchronous execution

From: Stefan Hajnoczi
Subject: Re: [Qemu-block] interesting blog post about asynchronous execution
Date: Tue, 24 Nov 2015 15:52:54 +0800
User-agent: Mutt/1.5.23 (2015-06-09)

On Mon, Nov 23, 2015 at 08:34:44PM +0100, Paolo Bonzini wrote:
> This is about the experience with asynchronous execution in Midori (a
> research OS written at Microsoft in a C#-like language, which was later
> turned into a playground for features to be added to C#):
> http://joeduffyblog.com/2015/11/19/asynchronous-everything/
> Some parts will definitely ring a bell, because the QEMU block layer has
> the same distinction between "await" and "async", only calls them
> bdrv_co_* and bdrv_aio_*.

Asynchronous everything in QEMU means entering a coroutine in
vl.c:main() and getting rid of blocking syscalls.  It would be nice
because it eliminates the blocking problems we have today.

The hardest situation I've seen is what to do with pending I/O requests.
Linux does not provide non-blocking cancellation.  This poses a problem
in cases like rebooting the guest and resetting devices.  A device
cannot just forget about pending host I/O requests during reset since
they may access memory in the future.  So it seems QEMU needs to wait
for all I/O requests to complete in order to reboot the guest.

Unless we find a solution to this problem we cannot go truly
asynchronous.  There will still be a synchronous bdrv_drain_all() for
reboot.  (In the live migration case we could do
bdrv_drain_all(timeout) and fail migration if a time limit is exceeded.)

There is also an implicit blocking point when terminating the QEMU
process.  Pending I/O requests are probably in 'D' state and the host
kernel cannot fully clean up the process until the I/O requests are
complete.  Therefore, even libvirt cannot get around the problem by
terminating QEMU and starting a fresh process.


Attachment: signature.asc
Description: PGP signature

reply via email to

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