From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YctW0-0004HR-TM for qemu-devel@nongnu.org; Tue, 31 Mar 2015 06:35:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YctVw-0007rm-KT for qemu-devel@nongnu.org; Tue, 31 Mar 2015 06:35:24 -0400 Received: from mail-wi0-x234.google.com ([2a00:1450:400c:c05::234]:35445) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YctVw-0007qu-Cz for qemu-devel@nongnu.org; Tue, 31 Mar 2015 06:35:20 -0400 Received: by widdi4 with SMTP id di4so3813265wid.0 for ; Tue, 31 Mar 2015 03:35:19 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <551A7864.9030806@redhat.com> Date: Tue, 31 Mar 2015 12:35:16 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1424449612-18215-1-git-send-email-pbonzini@redhat.com> In-Reply-To: <1424449612-18215-1-git-send-email-pbonzini@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 0/3] iothread: release iothread around aio_poll List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: famz@redhat.com, stefanha@redhat.com On 20/02/2015 17:26, Paolo Bonzini wrote: > Right now, iothreads are relying on a "contention callback" to release > the AioContext (e.g. for block device operations or to do bdrv_drain_all). > This is necessary because aio_poll needs to be called within an > aio_context_acquire. > > This series drops this requirement for aio_poll, with two effects: > > 1) it makes it possible to remove the "contention callback" in RFifoLock > (and possibly to convert it to a normal GRecMutex, which is why I am not > including a patch to remove callbacks from RFifoLock). > > 2) it makes it possible to start work around making critical sections > for the block layer fine-grained. > > In order to do this, some data is moved from AioContext to local storage. > Stack allocation has size limitations, so thread-local storage is used > instead. There are no reentrancy problems because the data is only live > throughout a small part of aio_poll, and in particular not during the > invocation of callbacks. > > Comments? Stefan, can you put this on track for 2.4 or do you need a repost? Paolo