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