From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLbsb-0004vK-RX for qemu-devel@nongnu.org; Tue, 09 Oct 2012 11:38:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLbsV-0003Vr-Ve for qemu-devel@nongnu.org; Tue, 09 Oct 2012 11:37:57 -0400 Received: from e23smtp05.au.ibm.com ([202.81.31.147]:42550) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLbsV-0003VD-EE for qemu-devel@nongnu.org; Tue, 09 Oct 2012 11:37:51 -0400 Received: from /spool/local by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 10 Oct 2012 01:36:18 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q99FbfOX28639268 for ; Wed, 10 Oct 2012 02:37:44 +1100 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q99FbeDl020831 for ; Wed, 10 Oct 2012 02:37:41 +1100 From: Anthony Liguori In-Reply-To: <50743D91.4010900@redhat.com> References: <1348577763-12920-1-git-send-email-pbonzini@redhat.com> <20121008113932.GB16332@stefanha-thinkpad.redhat.com> <5072CE54.8020208@redhat.com> <20121009090811.GB13775@stefanha-thinkpad.redhat.com> <877gqzn0xc.fsf@codemonkey.ws> <50743D91.4010900@redhat.com> Date: Tue, 09 Oct 2012 10:37:33 -0500 Message-ID: <87391n8xmq.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Stefan Hajnoczi , Ping Fan Liu , qemu-devel@nongnu.org, Avi Kivity Paolo Bonzini writes: > Il 09/10/2012 17:02, Anthony Liguori ha scritto: >> We've discussed previously about having an additional layer on top of >> the block API. >> >> One problem with the block API today is that it doesn't distinguish >> between device access and internal access. I think this is an >> opportunity to introduce a device-only API. > > And what API would libqblock use? !device-only API > I don't think this is a good idea unless we can prove performance problems. Let's separate out the two things. A device specific API has some advantages. I'm pretty sure it's a hard requirement for Kemari (they need to use device I/O as quiescent points). It makes testing easier too (simplier interface). But it also lets us do a short-term hack. That's all I'm suggesting here. A short term fast path. >> In the very short term, I can imagine an aio fastpath that was only >> implemented in terms of the device API. We could have a slow path that >> acquired the BQL. > > Not sure I follow. As long as the ioeventfd thread can acquire qemu_mutex in order to call bdrv_* functions. The new device-only API could do this under the covers for everything but the linux-aio fast path initially. That means that we can convert block devices to use the device-only API across the board (provided we make BQL recursive). It also means we get at least some of the benefits of data-plane in the short term. >> > 4. Unlocked event loop thread. This is simlar to QEMU's iothread except it >> > doesn't take the big lock. In theory we could have several of these threads >> > processing at the same time. virtio-blk ioeventfd processing will be done >> > in this thread. >> >> I think we're reasonable close to being able to do this FWIW. > > Yes, I'm resending this series with your comments addressed. It strays > a bit between your territory (main-loop) and Kevin's, I'll let you two > sort it out. I was very happy with it so as long as Kevin is willing to Ack it, I'm happy to apply it. Regards, Anthony Liguori > > Paolo