[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-2.1] AioContext: do not rely on aio_poll(ctx
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH for-2.1] AioContext: do not rely on aio_poll(ctx, true) result to end a loop |
Date: |
Wed, 9 Jul 2014 14:56:57 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Am 09.07.2014 um 10:49 hat Paolo Bonzini geschrieben:
> Currently, whenever aio_poll(ctx, true) has completed all pending
> work it returns true *and* the next call to aio_poll(ctx, true)
> will not block.
>
> This invariant has its roots in qemu_aio_flush()'s implementation
> as "while (qemu_aio_wait()) {}". However, qemu_aio_flush() does
> not exist anymore and bdrv_drain_all() is implemented differently;
> and this invariant is complicated to maintain and subtly different
> from the return value of GMainLoop's g_main_context_iteration.
>
> All calls to aio_poll(ctx, true) except one are guarded by a
> while() loop checking for a request to be incomplete, or a
> BlockDriverState to be idle. The one remaining call (in
> iothread.c) uses this to delay the aio_context_release/acquire
> pair until the AioContext is quiescent, however:
>
> - we can do the same just by using non-blocking aio_poll,
> similar to how vl.c invokes main_loop_wait
>
> - it is buggy, because it does not ensure that the AioContext
> is released between an aio_notify and the next time the
> iothread goes to sleep. This leads to hangs when stopping
> the dataplane thread.
>
> In the end, these semantics are a bad match for the current
> users of AioContext. So modify that one exception in iothread.c,
> which also fixes the hangs, as well as the testcase so that
> it use the same idiom as the actual QEMU code.
>
> Reported-by: Christian Borntraeger <address@hidden>
> Tested-by: Christian Borntraeger <address@hidden>
> Signed-off-by: Paolo Bonzini <address@hidden>
Thanks, applied to the block branch.
Kevin