From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHMDv-0006ln-4X for qemu-devel@nongnu.org; Mon, 20 Jul 2015 21:20:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZHMDr-0000yA-W8 for qemu-devel@nongnu.org; Mon, 20 Jul 2015 21:19:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHMDr-0000y4-R4 for qemu-devel@nongnu.org; Mon, 20 Jul 2015 21:19:55 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 489762F66B2 for ; Tue, 21 Jul 2015 01:19:55 +0000 (UTC) Date: Tue, 21 Jul 2015 09:19:53 +0800 From: Fam Zheng Message-ID: <20150721011953.GA1950@ad.nay.redhat.com> References: <1437370031-9070-1-git-send-email-pbonzini@redhat.com> <20150720074625.GA20738@ad.nay.redhat.com> <20150720100648.GA22650@ad.nay.redhat.com> <1108497253.1650856.1437396175024.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1108497253.1650856.1437396175024.JavaMail.zimbra@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2] AioContext: fix broken placement of event_notifier_test_and_clear List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kwolf@redhat.com, lersek@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, rjones@redhat.com On Mon, 07/20 08:42, Paolo Bonzini wrote: > > > > I'm looking at optimizing it but I don't fully understand the relationship > > > between aio_prepare and WaitForMultipleObjects. Do they get the same set of > > > events? > > > > After some reading I think WaitForMultipleObjects is for event notifiers and > > aio_prepare is for select() on fd events. > > It's a bit trickier than aio-posix, in the first iteration there could be > > another event masking ctx->notifier so we don't know if we need to clear it. > > Maybe we can reverse events[] so that ctx->notifier will be the 0th one. And I > > think we can always remove it after first iteration, am I right? > > Yes, that would work. I am not sure how complex it would be. You would also need > a solution for the GSource and one (probably similar to aio-posix) for your > epoll implementation. With ctx->notified at least you can encapsulate it in > aio_notify_accept... Yes, I'll take this into consideration when I refactor for epoll implementation. For now I think aio_notify_accept is cleaner. Fam