From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39573) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bP2dV-0006wx-8P for qemu-devel@nongnu.org; Mon, 18 Jul 2016 03:06:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bP2dQ-0005Zh-7b for qemu-devel@nongnu.org; Mon, 18 Jul 2016 03:06:41 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:35001 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bP2dP-0005Z6-Tk for qemu-devel@nongnu.org; Mon, 18 Jul 2016 03:06:36 -0400 References: <577A6955.6020603@kamp.de> <577B130A.3040205@redhat.com> <3221d3d3-37ee-9752-396e-379792445ee0@redhat.com> <577BCB35.6060103@redhat.com> <1a6cbf2d-ff64-0994-23b4-eb305d5ce35f@redhat.com> <5788B660.2060001@kamp.de> <578903FF.2050400@redhat.com> From: Peter Lieven Message-ID: <578C7FEF.3070100@kamp.de> Date: Mon, 18 Jul 2016 09:06:23 +0200 MIME-Version: 1.0 In-Reply-To: <578903FF.2050400@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , Paolo Bonzini , "qemu-devel@nongnu.org" Cc: Kevin Wolf Am 15.07.2016 um 17:40 schrieb Eric Blake: > On 07/15/2016 04:09 AM, Peter Lieven wrote: >> Am 05.07.2016 um 17:09 schrieb Paolo Bonzini: >>> On 05/07/2016 16:59, Eric Blake wrote: >>>> And yes, we could probably switch to (potentially slower) / % * instead >>>> of bit operations in block/io.c to accommodate a non-power-of-2 optimal >>>> size, but it would require a careful audit to make sure we don't have >>>> even more bit-wise operations lurking that were assuming a power of 2. >>> Yes, it would require some auditing but it has always worked. Regarding >>> speed, I'm sure that / % * are not slower than a system call! :) >> Eric, whats the status of this? Will you send a follow-up to your series >> restoring the old behaviour? > Still on my plate. As it is a bug-fix, the patch can go in even after > hard freeze, so at the moment I've unfortunately been more focused on > other patches (such as NBD_CMD_WRITE_ZEROES support) that were posted > before soft freeze, but which must be committed prior to hard freeze or > else they miss 2.7. But rest assured that I'll make sure 2.7 doesn't > regress on your setup. Okay, thanks for the update. Peter