[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH 0/4] aio: Don't poll ioeventfd in nested aio_poll()
Date: Thu, 28 May 2015 14:01:34 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

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?


reply via email to

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