From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: eesposit@redhat.com, vsementsov@virtuozzo.com,
stefanha@redhat.com, qemu-devel@nongnu.org,
qemu-block@nongnu.org
Subject: Re: [PATCH v2] async: the main AioContext is only "current" if under the BQL
Date: Wed, 9 Jun 2021 15:02:07 +0200 [thread overview]
Message-ID: <YMC7z/86LurXvAQ6@redhat.com> (raw)
In-Reply-To: <20210609122234.544153-1-pbonzini@redhat.com>
Am 09.06.2021 um 14:22 hat Paolo Bonzini geschrieben:
> If we want to wake up a coroutine from a worker thread, aio_co_wake()
> currently does not work. In that scenario, aio_co_wake() calls
> aio_co_enter(), but there is no current AioContext and therefore
> qemu_get_current_aio_context() returns the main thread. aio_co_wake()
> then attempts to call aio_context_acquire() instead of going through
> aio_co_schedule().
>
> The default case of qemu_get_current_aio_context() was added to cover
> synchronous I/O started from the vCPU thread, but the main and vCPU
> threads are quite different. The main thread is an I/O thread itself,
> only running a more complicated event loop; the vCPU thread instead
> is essentially a worker thread that occasionally calls
> qemu_mutex_lock_iothread(). It is only in those critical sections
> that it acts as if it were the home thread of the main AioContext.
>
> Therefore, this patch detaches qemu_get_current_aio_context() from
> iothreads, which is a useless complication. The AioContext pointer
> is stored directly in the thread-local variable, including for the
> main loop. Worker threads (including vCPU threads) optionally behave
> as temporary home threads if they have taken the big QEMU lock,
> but if that is not the case they will always schedule coroutines
> on remote threads via aio_co_schedule().
>
> With this change, qemu_mutex_iothread_locked() must be changed from
> true to false. The previous value of true was needed because the
> main thread did not have an AioContext in the thread-local variable,
> but now it does have one.
>
> Reported-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The commit message doesn't specify, but in the buggy case, are we
talking about calling aio_co_wake() for a coroutine in the main context
specifically, right? Could we have a unit test for this scenario?
But the change looks reasonable to me.
Kevin
next prev parent reply other threads:[~2021-06-09 13:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-09 12:22 [PATCH v2] async: the main AioContext is only "current" if under the BQL Paolo Bonzini
2021-06-09 13:02 ` Kevin Wolf [this message]
2021-06-09 15:05 ` Vladimir Sementsov-Ogievskiy
2021-06-11 11:13 ` Paolo Bonzini
2021-06-14 11:34 ` Paolo Bonzini
2021-06-09 15:01 ` Vladimir Sementsov-Ogievskiy
2021-06-11 11:14 ` Paolo Bonzini
2021-06-11 15:58 ` Eric Blake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YMC7z/86LurXvAQ6@redhat.com \
--to=kwolf@redhat.com \
--cc=eesposit@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).