From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLwNX-00072U-50 for qemu-devel@nongnu.org; Wed, 10 Oct 2012 09:31:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLwNP-0007ax-Au for qemu-devel@nongnu.org; Wed, 10 Oct 2012 09:31:15 -0400 Received: from mail-da0-f45.google.com ([209.85.210.45]:34328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLwNP-0007aq-4J for qemu-devel@nongnu.org; Wed, 10 Oct 2012 09:31:07 -0400 Received: by mail-da0-f45.google.com with SMTP id n15so176663dad.4 for ; Wed, 10 Oct 2012 06:31:06 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <50757894.2000703@redhat.com> Date: Wed, 10 Oct 2012 15:31:00 +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> <50743D91.4010900@redhat.com> <87391n8xmq.fsf@codemonkey.ws> <5074502F.5030706@redhat.com> <87ehl7lcxu.fsf@codemonkey.ws> <50751FAB.1000201@redhat.com> <87haq2ldjr.fsf@codemonkey.ws> In-Reply-To: <87haq2ldjr.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 10/10/2012 14:25, Anthony Liguori ha scritto: >> > NBD uses coroutines; curl can use the non-unlocked >> > bdrv_aio_readv/writev. In both cases they would execute in the >> > dataplane thread. qcow2-over-raw would also execute its read/write code >> > entirely from the dataplane thread, for example. > Does that mean that we'd stop processing the queue if we're waiting for > an I/O completion to handle meta data operations? > > If that's the case, that probably will hurt performance overall. >>From discussion on IRC it looked like this was ENOCAFFEINE. :) Paolo