Re: [Qemu-devel] [RFC PATCH 0/4] aio: Don't poll ioeventfd in nested aio_poll()

[Paolo Bonzini <pbonzini@redhat.com>]

On 28/05/2015 13:49, Fam Zheng wrote:
> On Thu, 05/28 13:19, Paolo Bonzini wrote:
>>
>>
>> On 28/05/2015 13:16, Fam Zheng wrote:
>>>> On 28/05/2015 03:46, Fam Zheng wrote:
>>>>> The main context uses iohandler and aio_dispatch, neither calls
>>>>> aio_set_dispatching(). However, if we have [2], they can be changed to
>>>>> aio_poll(), then would this idea work?
>>>>
>>>> I think it's a bad idea to handle aio_poll for context B in a different
>>>> way, just because you have an outer aio_poll for context A...
>>>
>>> But we already do something similar: ignoring slirp, main_loop_wait() is like
>>> an iothread aio_poll() without the "outermost differentiation", while the
>>> current aio_poll() in bdrv_drain() is roughly "main_loop_wait() minus
>>> iohandlers".
>>
>> Right, but the two sets of iohandlers are stored in different places, so
>> it's obvious that you don't execute all of them.  On the other hand,
>> examining global state in aio_poll is really bad.
>>
> 
> OK.
> 
> Would moving the ioeventfds to a new top level aio_loop_wait() be any better?
> That way no global state is needed.

If we need pause/resume anyway due to block/mirror.c's use of
block_job_defer_to_main_loop, I think this is not a problem anymore?

Paolo