qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]