Re: [Qemu-devel] [PATCH v3 09/10] aio: add .io_poll_begin/end() callbacks

[Paolo Bonzini <pbonzini@redhat.com>]

On 23/11/2016 10:44, Stefan Hajnoczi wrote:
> I thought about the final poll but decided it was nicer for virtio.c to
> do it internally.  Not all .io_poll_end() implementations may require an
> additional poll so it seemed more optimal to leave it up to each
> callback.
> 
> If you prefer the run_poll_handlers_once(ctx) approach I'll switch to
> that.

I think the question is more whether it makes sense to poll once even
for non-blocking aio_poll.  I think it does; after all, why even call
ppoll() if all sources support polling and you don't need to sleep? :)

Doing the run_poll_handlers_once automatically after .io_poll_end()
would be a side effect of how to write that code, but it's the less
interesting part.

BTW, iothread.c doesn't use non-blocking aio_poll, but there are
interesting opportunities for (micro)optimization of the event loop
involving non-blocking mode.  For example we could add a

    if (atomic_read(&ctx->notified)) {
        blocking = false;
    }

at the beginning of aio_poll.  When a bottom half is scheduled, this
would avoid further notifications (notify_me stays zero) and skip
aio_compute_timeout.  I think it's worthwhile for aio=threads, but it
would be a pity to lose polling in this case.  The null backend also
uses bottom halves heavily, either directly for null-aio:// or through
bdrv_co_maybe_schedule_bh for null-co://.

Paolo