From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLYlU-0002wi-DX for qemu-devel@nongnu.org; Tue, 09 Oct 2012 08:18:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLYlN-0002DP-Q8 for qemu-devel@nongnu.org; Tue, 09 Oct 2012 08:18:24 -0400 Received: from thoth.sbs.de ([192.35.17.2]:24626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLYlN-0002BM-GQ for qemu-devel@nongnu.org; Tue, 09 Oct 2012 08:18:17 -0400 Message-ID: <507415FF.3050402@siemens.com> Date: Tue, 09 Oct 2012 14:18:07 +0200 From: Jan Kiszka 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> In-Reply-To: <50741218.90000@redhat.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: Paolo Bonzini Cc: Kevin Wolf , Anthony Liguori , Ping Fan Liu , Stefan Hajnoczi , "qemu-devel@nongnu.org" , Avi Kivity On 2012-10-09 14:01, Paolo Bonzini wrote: > Il 09/10/2012 13:55, Avi Kivity ha scritto: >> Oh, agree 100% raw + native aio wants to bypass coroutines/threads >> completely. > > Even posix-aio-compat can bypass coroutines. > >> We could perhaps even avoid refcounting, by shutting down the device >> thread as part of hotunplug. > > Yes, you "just" join the thread, ask it to exit, and not hot-unplug > until it's done. > >> [could we also avoid refcounting by doing the equivalent of >> stop_machine() during hotunplug?] > > That's quite an interesting alternative. 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. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux