Re: [Qemu-devel] [RFC PATCH 00/17] Support for multiple "AIO contexts"

[Paolo Bonzini <pbonzini@redhat.com>]

Il 26/09/2012 14:28, Kevin Wolf ha scritto:
> Do you have a git tree where I could see what things would look like in
> the end?

I will push it to aio-context on git://github.com/bonzini/qemu.git as
soon as github comes back.

> I wonder how this relates to my plans of getting rid of qemu_aio_flush()
> and friends in favour of BlockDriver.bdrv_drain().

Mostly unrelated, I think.  The introduction of the non-blocking
aio_poll in this series might help implementing bdrv_drain, like this:

    blocking = false;
    while(bs has requests) {
        progress = aio_poll(aio context of bs, blocking);
        if (progress) {
            blocking = false;
            continue;
        }
        if (bs has throttled requests) {
            restart throttled requests
            blocking = false;
            continue;
        }

        /* No progress, must have been non-blocking.  We must wait.  */
        assert(!blocking);
        blocking = true;
    }

BTW, is it true that "bs->file has requests || bs->backing_hd has
requests" (or any other underlying file, like vmdk extents) implies "bs
has requests"?

> In fact, after removing io_flush, I don't really see what makes AIO
> fd handlers special any more.

Note that while the handlers aren't that special indeed, there is still
some magic because qemu_aio_wait() bottom halves.

> qemu_aio_wait() only calls these handlers, but would it do any harm if
> we called all fd handlers?

Unfortunately yes.  You could get re-entrant calls from the monitor
while a monitor command drains the AIO queue for example.

> And other than that it's just a small main
> loop, so I guess it could share code with the real main loop.

Yes, the nested (and blocking) event loops are ugly.  On the other hand,
it is even uglier to have hooks to call the main loop from aio.c (for
handlers) and vice versa (for bottom halves).  One of the points of the
series is to make AIO just another GSource, with the bottom half magic
and fdhandler hooks handled in a single place (async.c).

Moving towards separate-thread event processing for one or more
BlockDriverStates can be done both with GMainLoop + GSource, or with
aio_poll.  I haven't put much thought in this, but a thread doing "while
(aio_poll(ctx, false));" would look very much like Stefan's data-plane code.

Paolo