From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57419) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9VGw-0001rT-0o for qemu-devel@nongnu.org; Wed, 23 Nov 2016 05:59:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9VGs-0002LL-Ni for qemu-devel@nongnu.org; Wed, 23 Nov 2016 05:59:26 -0500 Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:37393) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c9VGs-0002LF-GV for qemu-devel@nongnu.org; Wed, 23 Nov 2016 05:59:22 -0500 Received: by mail-wm0-x229.google.com with SMTP id t79so18206869wmt.0 for ; Wed, 23 Nov 2016 02:59:22 -0800 (PST) Sender: Paolo Bonzini References: <1479832306-26440-1-git-send-email-stefanha@redhat.com> <1479832306-26440-10-git-send-email-stefanha@redhat.com> <20161123094441.GD20034@stefanha-x1.localdomain> From: Paolo Bonzini Message-ID: <6b09dd0e-0aa5-db85-1251-acac9e2158fa@redhat.com> Date: Wed, 23 Nov 2016 11:59:18 +0100 MIME-Version: 1.0 In-Reply-To: <20161123094441.GD20034@stefanha-x1.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v3 09/10] aio: add .io_poll_begin/end() callbacks List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: borntraeger@de.ibm.com, Fam Zheng , qemu-devel@nongnu.org, Stefan Hajnoczi , Karl Rister On 23/11/2016 10:44, Stefan Hajnoczi wrote: > I thought about the final poll but decided it was nicer for virtio.c to > do it internally. Not all .io_poll_end() implementations may require an > additional poll so it seemed more optimal to leave it up to each > callback. > > If you prefer the run_poll_handlers_once(ctx) approach I'll switch to > that. I think the question is more whether it makes sense to poll once even for non-blocking aio_poll. I think it does; after all, why even call ppoll() if all sources support polling and you don't need to sleep? :) Doing the run_poll_handlers_once automatically after .io_poll_end() would be a side effect of how to write that code, but it's the less interesting part. BTW, iothread.c doesn't use non-blocking aio_poll, but there are interesting opportunities for (micro)optimization of the event loop involving non-blocking mode. For example we could add a if (atomic_read(&ctx->notified)) { blocking = false; } at the beginning of aio_poll. When a bottom half is scheduled, this would avoid further notifications (notify_me stays zero) and skip aio_compute_timeout. I think it's worthwhile for aio=threads, but it would be a pity to lose polling in this case. The null backend also uses bottom halves heavily, either directly for null-aio:// or through bdrv_co_maybe_schedule_bh for null-co://. Paolo