From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLYvT-00068e-Iu for qemu-devel@nongnu.org; Tue, 09 Oct 2012 08:28:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLYvO-0005q8-GB for qemu-devel@nongnu.org; Tue, 09 Oct 2012 08:28:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43997) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLYvO-0005q2-87 for qemu-devel@nongnu.org; Tue, 09 Oct 2012 08:28:38 -0400 Message-ID: <5074186D.8060002@redhat.com> Date: Tue, 09 Oct 2012 14:28:29 +0200 From: Avi Kivity 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> <5073EDB3.3020804@redhat.com> <5073FE3A.1090903@redhat.com> <507401D8.8090203@redhat.com> <507405B5.4060108@redhat.com> <507410BD.6050901@redhat.com> <50741218.90000@redhat.com> <507415FF.3050402@siemens.com> In-Reply-To: <507415FF.3050402@siemens.com> 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: Jan Kiszka Cc: Kevin Wolf , Anthony Liguori , Ping Fan Liu , Stefan Hajnoczi , "qemu-devel@nongnu.org" , Paolo Bonzini On 10/09/2012 02:18 PM, Jan Kiszka wrote: > Not sure about the full context of this discussion, but I played with > "stop-machine" (pause_all_vcpus) recently. The problem is, at least ATM, > that it drops the BQL to wait for those threads, and that creates an > unexpected rescheduling point over which a lot of code stumbles. But if > this case here is about new, accordingly written code that is also not > called from unprepared corners, it may work. In theory we could make qemu_mutex_lock() detect that it's being stop_machine()d and loop there - stop_machine() would just keep the lock held. But that's not doable easily with pthreads (there is no mutex_lock_interruptible() equivalent). In any case I've cooled down on stop_machine(), see sibling reply. -- error compiling committee.c: too many arguments to function