From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLbPP-0004Qv-P4 for qemu-devel@nongnu.org; Tue, 09 Oct 2012 11:07:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLbPF-0008Rx-Ay for qemu-devel@nongnu.org; Tue, 09 Oct 2012 11:07:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLbPF-0008Ra-1V for qemu-devel@nongnu.org; Tue, 09 Oct 2012 11:07:37 -0400 Message-ID: <50743D91.4010900@redhat.com> Date: Tue, 09 Oct 2012 17:06:57 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <877gqzn0xc.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Anthony Liguori Cc: Kevin Wolf , Stefan Hajnoczi , Ping Fan Liu , qemu-devel@nongnu.org, Avi Kivity 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? I don't think this is a good idea unless we can prove performance problems. > 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. > > 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. Paolo