From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZIBfK-0007SW-0G for qemu-devel@nongnu.org; Thu, 23 Jul 2015 04:15:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZIBfE-0007Zc-U7 for qemu-devel@nongnu.org; Thu, 23 Jul 2015 04:15:41 -0400 References: <1437633138-29188-1-git-send-email-famz@redhat.com> From: Paolo Bonzini Message-ID: <55B0A298.4020405@redhat.com> Date: Thu, 23 Jul 2015 10:15:20 +0200 MIME-Version: 1.0 In-Reply-To: <1437633138-29188-1-git-send-email-famz@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH 00/11] aio: Introduce handler type to fix nested aio_poll for dataplane List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , qemu-devel@nongnu.org Cc: kwolf@redhat.com, stefanha@redhat.com, qemu-block@nongnu.org On 23/07/2015 08:32, Fam Zheng wrote: >=20 > What is realized in this series is similar except the "disable, poll, e= nable" > method, instead the bit mask of interesting client types is passed to > aio_poll() (to be exact, passed to aio_poll_clients()). That is because= , > aio_poll may release the AioContext lock around ppoll, avoiding state w= ill make > the interface clearer. However, this means that you must keep the AioContext lock during all the long-running operations. Is this actually necessary? The original purpose of keeping the lock (which didn't quite work) was to block out dataplane operations. Also, this requirements means you really need the AioContext lock to be recursive. This is not a huge deal, but I'd prefer that requirement not to be too ingrained. Paolo > After this series, block layer aio_poll() will only process those "prot= ocol" > fds that are used in block I/O, plus the ctx->notifier for aio_notify()= ; other > aio_poll()'s keep unchanged. >=20 > The biggest advantage over approaches [1] and [2] is, no change is need= ed in > virtio-{blk,scsi}-dataplane code, also this doesn't depend on convertin= g QMP to > coroutines.