From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bD8Cb-0005vC-4m for qemu-devel@nongnu.org; Wed, 15 Jun 2016 06:37:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bD8CW-00055m-0b for qemu-devel@nongnu.org; Wed, 15 Jun 2016 06:37:40 -0400 Received: from mx1.parallels.com ([199.115.104.18]:43149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bD8CV-00054a-Qd for qemu-devel@nongnu.org; Wed, 15 Jun 2016 06:37:35 -0400 References: <1465917916-22348-1-git-send-email-den@openvz.org> <1465917916-22348-6-git-send-email-den@openvz.org> <5760C98F.4010600@redhat.com> <20160615091943.GA26488@stefanha-x1.localdomain> From: "Denis V. Lunev" Message-ID: <57612FDE.2090304@virtuozzo.com> Date: Wed, 15 Jun 2016 13:37:18 +0300 MIME-Version: 1.0 In-Reply-To: <20160615091943.GA26488@stefanha-x1.localdomain> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 5/9] mirror: improve performance of mirroring of empty disk List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , Eric Blake Cc: Kevin Wolf , vsementsov@virtuozzo.com, Fam Zheng , qemu-block@nongnu.org, Jeff Cody , qemu-devel@nongnu.org, Max Reitz , "Denis V. Lunev" On 06/15/2016 12:19 PM, Stefan Hajnoczi wrote: > On Tue, Jun 14, 2016 at 09:20:47PM -0600, Eric Blake wrote: >> On 06/14/2016 09:25 AM, Denis V. Lunev wrote: >>> We should not take into account zero blocks for delay calculations. >>> They are not read and thus IO throttling is not required. In the >>> other case VM migration with 16 Tb QCOW2 disk with 4 Gb of data takes >>> days. >>> >>> Signed-off-by: Denis V. Lunev >>> Reviewed-by: Vladimir Sementsov-Ogievskiy >>> CC: Stefan Hajnoczi >>> CC: Fam Zheng >>> CC: Kevin Wolf >>> CC: Max Reitz >>> CC: Jeff Cody >>> CC: Eric Blake >>> --- >>> block/mirror.c | 7 +++++-- >>> 1 file changed, 5 insertions(+), 2 deletions(-) >> Seems reasonable, but I'll let others more familiar with throttling give >> the final say. > There is a bounce buffer fallback when !drv->bdrv_co_pwrite_zeroes. In > that case we need to account for the bytes transferred. I don't see > where the patch takes this into account. Interesting point. I think we are charging for IO performed. Thus with the absence of the callback we should charge for io_sectors/2 The write will be full scale, there is no reading. Correct?