[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 05/16] iothread: release AioContext around aio_p
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH 05/16] iothread: release AioContext around aio_poll |
Date: |
Tue, 2 Feb 2016 14:52:06 +0000 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Fri, Jan 15, 2016 at 04:12:08PM +0100, Paolo Bonzini wrote:
> @@ -120,9 +117,17 @@ Block layer code must therefore expect to run in an
> IOThread and avoid using
> old APIs that implicitly use the main loop. See the "How to program for
> IOThreads" above for information on how to do that.
>
> -If main loop code such as a QMP function wishes to access a BlockDriverState
> it
> -must first call aio_context_acquire(bdrv_get_aio_context(bs)) to ensure the
> -IOThread does not run in parallel.
> +If main loop code such as a QMP function wishes to access a BlockDriverState
> +it must first call aio_context_acquire(bdrv_get_aio_context(bs)) to ensure
> +that callbacks in the IOThread do not run in parallel.
> +
> +Code running in the monitor typically uses bdrv_drain() to ensure that
> +past requests from the guest are completed. When a block device is
> +running in an IOThread, the IOThread can also process requests from
> +the guest (via ioeventfd). These requests have to be blocked with
> +aio_disable_clients() before calling bdrv_drain(). You can then reenable
> +guest requests with aio_enable_clients() before finally releasing the
> +AioContext and completing the monitor command.
This is outdated. Monitor commands do this:
bdrv_drained_begin() -> ... -> bdrv_drain() -> ... -> bdrv_drained_end()
> @@ -110,6 +111,8 @@ static void *test_acquire_thread(void *opaque)
> qemu_mutex_lock(&data->start_lock);
> qemu_mutex_unlock(&data->start_lock);
>
> + g_usleep(500000);
Sleep?
signature.asc
Description: PGP signature
- Re: [Qemu-devel] [PATCH 05/16] iothread: release AioContext around aio_poll,
Stefan Hajnoczi <=