[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 0/5] nbd: Adapt for dataplane
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [RFC 0/5] nbd: Adapt for dataplane |
Date: |
Wed, 4 Jun 2014 14:47:31 +0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Sat, May 31, 2014 at 10:24:47PM +0200, Max Reitz wrote:
> On 31.05.2014 20:43, Max Reitz wrote:
> >[snip]
> >
> >However, if bs_aio_detach() is called from a different thread than the
> >old AioContext is running in, we may still have coroutines running for
> >which we should wait before returning from bs_aio_detach().
>
> After re-reading Stefan's RFC and the AIO locking code, would it suffice to
> call aio_context_acquire() and aio_context_release() on the old AioContext
> at the end of bs_aio_detach() to ensure all coroutines are settled? If not,
> I guess I have to wait until the coroutine variables are set to NULL (which
> indicates they have completely finished execution; however, this is not
> actually necessary and might lead to an infinite loop if the block driver
> keeps yielding due to some condition related to the AioContext switch), or I
> really have to switch the existing coroutines to the new AioContext while
> they are running. Doing this from the outside will probably be even messier
> than it would already be from the inside, so I sure hope to be able to avoid
> this…
I think you don't need to worry about this at all.
bdrv_set_aio_context() is always invoked with the QEMU global mutex
held.
Regarding switching a coroutine from one AioContext to another (possibly
in another thread), I've implemented it but it's a little involved
(complex and slow). Let's avoid it, if possible. I also lost the patch
during the great "make distclean twice deletes .git/" fiasco of 2014 so
would need to reimplement it :).
Stefan