From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxwVW-0000Be-1g for qemu-devel@nongnu.org; Thu, 28 May 2015 08:01:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxwVR-0000b8-76 for qemu-devel@nongnu.org; Thu, 28 May 2015 08:01:53 -0400 Message-ID: <5567039E.2020509@redhat.com> Date: Thu, 28 May 2015 14:01:34 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1432711146-28405-1-git-send-email-famz@redhat.com> <556590B1.2040405@redhat.com> <20150528014615.GA22609@dhcp-14-238.nay.redhat.com> <5566D000.3030101@redhat.com> <20150528111656.GD8461@dhcp-14-238.nay.redhat.com> <5566F9A8.4020702@redhat.com> <20150528114901.GF8461@dhcp-14-238.nay.redhat.com> In-Reply-To: <20150528114901.GF8461@dhcp-14-238.nay.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/4] aio: Don't poll ioeventfd in nested aio_poll() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Kevin Wolf , qemu-block@nongnu.org, "Michael S. Tsirkin" , Stefan Weil , qemu-devel@nongnu.org, Stefan Hajnoczi 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