From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agJwH-0008CJ-1W for qemu-devel@nongnu.org; Wed, 16 Mar 2016 18:29:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agJwG-00012S-7E for qemu-devel@nongnu.org; Wed, 16 Mar 2016 18:29:12 -0400 Sender: Paolo Bonzini References: <1455645388-32401-1-git-send-email-pbonzini@redhat.com> <20160316181819.GD2012@stefanha-x1.localdomain> From: Paolo Bonzini Message-ID: <56E9DE2E.5060607@redhat.com> Date: Wed, 16 Mar 2016 23:29:02 +0100 MIME-Version: 1.0 In-Reply-To: <20160316181819.GD2012@stefanha-x1.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 00/16] AioContext fine-grained locking, part 1 of 3, including bdrv_drain rewrite List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org On 16/03/2016 19:18, Stefan Hajnoczi wrote: > Looks good overall. I'm a little nervous about merging it for QEMU 2.6 > but the block job, NBD, and data plane tests should give it a good > workout. Apart from QEMU nearing hard freeze, I totally understand not wanting to commit to merging part 1 of n where n will probably be a dozen or so. I'm open to experimenting with different models for handling long-term contributions. For example, each part will probably have an uncontroversial and generally useful prefix---for example patches 1-4 in this case, or the change to a single linux-aio context per iothread. You could merge those only, and for the rest, I will maintain myself a branch with R-b from maintainers. Master will be periodically merged into it, but not too frequently---it could be only after each part is accepted, or when there is some important bugfix to catch. Once the whole multiqueue thing gets somewhere I would send you a pull request with the entire feature, which would consist of say 200 patches all with a Reviewed-by already. This is just a possibility; if you have any other idea, I'd be happy to follow it. Paolo