On Wed, Jan 18, 2017 at 04:40:29PM +0100, Paolo Bonzini wrote:
> On 18/01/2017 15:33, Stefan Hajnoczi wrote:
> > On Fri, Jan 13, 2017 at 02:17:16PM +0100, Paolo Bonzini wrote:
> >> +static void co_schedule_bh_cb(void *opaque)
> >> +{
> >> + AioContext *ctx = opaque;
> >> + QSLIST_HEAD(, Coroutine) straight, reversed;
> >> +
> >> + QSLIST_MOVE_ATOMIC(&reversed, &ctx->scheduled_coroutines);
> >> + QSLIST_INIT(&straight);
> >> +
> >> + while (!QSLIST_EMPTY(&reversed)) {
> >> + Coroutine *co = QSLIST_FIRST(&reversed);
> >> + QSLIST_REMOVE_HEAD(&reversed, co_scheduled_next);
> >> + QSLIST_INSERT_HEAD(&straight, co, co_scheduled_next);
> >> + }
> >> +
> >> + while (!QSLIST_EMPTY(&straight)) {
> >> + Coroutine *co = QSLIST_FIRST(&straight);
> >> + QSLIST_REMOVE_HEAD(&straight, co_scheduled_next);
> >> + trace_aio_co_schedule_bh_cb(ctx, co);
> >> + qemu_coroutine_enter(co);
> >> + }
> >> +}
> >
> > ctx->scheduled_coroutines is a specialized CoQueue. Was there no way to
> > modify and then use CoQueue instead of open coding it?
>
> First of all, I'm trying to avoid a circular dependency when CoQueue can
> use aio_co_schedule (indirectly through aio_co_wake) after patch 7.
>
> Secondarily, co_schedule_bh_cb can perform a single pass on
> ctx->scheduled_coroutines because it will be rescheduled by
> aio_co_schedule. The same is not true for qemu_co_queue_restart_all.
>
> Also, CoQueue can have multiple consumers, while scheduled_coroutines
> cannot. Currently, CoQueue needs no thread-safety because it's
> protected by AioContext and/or by the non-preemptive nature of
> coroutines. Later, it's going to be protected by an external CoMutex,
> just like a mutex/condvar pair. scheduled_coroutines is different in
> this respect.
Thanks for explaining.
> >> +void aio_co_wake(struct Coroutine *co)
> >> +{
> >> + AioContext *ctx;
> >> +
> >> + /* Read coroutine before co->ctx. Matches smp_wmb in
> >> + * qemu_coroutine_enter.
> >> + */
> >> + smp_read_barrier_depends();
> >> + ctx = atomic_read(&co->ctx);
> >> +
> >> + if (ctx != qemu_get_current_aio_context()) {
> >> + aio_co_schedule(ctx, co);
> >> + return;
> >> + }
> >> +
> >> + if (qemu_in_coroutine()) {
> >> + Coroutine *self = qemu_coroutine_self();
> >> + assert(self != co);
> >> + QSIMPLEQ_INSERT_TAIL(&self->co_queue_wakeup, co, co_queue_next);
> >> + } else {
> >> + aio_context_acquire(ctx);
> >> + qemu_coroutine_enter(co);
> >> + aio_context_release(ctx);
> >
> > Why is it necessary to acquire AioContext here? We're already in ctx.
>
> We're in its thread, but we've not necessarily acquired it yet.
> aio_co_wake is called "aio_*" because it's a central place for
> AioContext to acquire itself for coroutines. This way, coroutines only
> care about CoMutexes, and not about AioContext. This was "highly
> recommended" :) by Kevin last year and it's the main change since the
> previous posting
> (https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg05416.html for
> example).
I see. That also explains why we don't need to acquire AioContext if
we're already in a coroutine.
signature.asc
Description: PGP signature
