[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 00/17] Support for multiple "AIO contexts"
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [RFC PATCH 00/17] Support for multiple "AIO contexts" |
Date: |
Wed, 26 Sep 2012 14:28:20 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 |
Am 25.09.2012 14:55, schrieb Paolo Bonzini:
> This series removes the globals from async.c/aio-posix.c so that
> multiple AIO contexts (mini event loops) can be added. Right now,
> all block devices still use qemu_bh_new, but switching them to
> aio_bh_new would let you associate different files with different
> AIO contexts.
>
> As an added bonus, integration with the glib main loop now happens
> via GSource. Each AIO context is a GSource, which means you can
> choose either to run it in its own thread (this of course needs
> proper locking which is not yet here), or to attach it to the main
> thread.
>
> In this state this is a bit of an academic exercise (though it works
> and may even make sense for 1.3), but I think it's an example of the
> tiny steps that can lead us towards an upstreamable version of the
> data-plane code.
Do you have a git tree where I could see what things would look like in
the end?
I wonder how this relates to my plans of getting rid of qemu_aio_flush()
and friends in favour of BlockDriver.bdrv_drain(). In fact, after
removing io_flush, I don't really see what makes AIO fd handlers special
any more.
qemu_aio_wait() only calls these handlers, but would it do any harm if
we called all fd handlers? And other than that it's just a small main
loop, so I guess it could share code with the real main loop.
So, considering this, any reason to let aio.c survive at all?
Kevin
- Re: [Qemu-devel] [PATCH 14/17] main-loop: use GSource to poll AIO file descriptors, (continued)