From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35669)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1Utv8l-0004qv-Ff
	for qemu-devel@nongnu.org; Tue, 02 Jul 2013 03:36:45 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1Utv8k-0007M6-6B
	for qemu-devel@nongnu.org; Tue, 02 Jul 2013 03:36:43 -0400
Received: from mail-we0-x232.google.com ([2a00:1450:400c:c03::232]:51049)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1Utv8j-0007M2-Vi
	for qemu-devel@nongnu.org; Tue, 02 Jul 2013 03:36:42 -0400
Received: by mail-we0-f178.google.com with SMTP id u53so4080029wes.9
	for <qemu-devel@nongnu.org>; Tue, 02 Jul 2013 00:36:41 -0700 (PDT)
Date: Tue, 2 Jul 2013 09:36:38 +0200
From: Stefan Hajnoczi <stefanha@gmail.com>
Message-ID: <20130702073638.GC6800@stefanha-thinkpad.redhat.com>
References: <1372338695-411-1-git-send-email-pl@kamp.de>
	<1372338695-411-9-git-send-email-pl@kamp.de>
	<20130701141305.GE20182@stefanha-thinkpad.redhat.com>
	<2AFC85D9-2A89-40ED-9EC2-948B0157611E@kamp.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2AFC85D9-2A89-40ED-9EC2-948B0157611E@kamp.de>
Subject: Re: [Qemu-devel] [PATCHv2 08/11] block-migration: efficiently
 encode zero blocks
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Lieven <pl@kamp.de>
Cc: kwolf@redhat.com, pbonzini@redhat.com, ronniesahlberg@gmail.com, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>

On Mon, Jul 01, 2013 at 06:09:55PM +0200, Peter Lieven wrote:
> 
> Am 01.07.2013 um 16:13 schrieb Stefan Hajnoczi <stefanha@redhat.com>:
> 
> > On Thu, Jun 27, 2013 at 03:11:32PM +0200, Peter Lieven wrote:
> >> 
> >>     /* device name */
> >>     len = strlen(blk->bmds->bs->device_name);
> >>     qemu_put_byte(f, len);
> >>     qemu_put_buffer(f, (uint8_t *)blk->bmds->bs->device_name, len);
> >> 
> >> +    /* if a block is zero we need to flush here since the network
> >> +     * bandwidth is now a lot higher than the storage device bandwidth.
> >> +     * thus if we queue zero blocks we slow down the migration */
> >> +    if (flags & BLK_MIG_FLAG_ZERO_BLOCK) {
> >> +        qemu_fflush(f);
> >> +        return;
> >> +    }
> > 
> > Not sure I understand this.  Is the problem that the other side may
> > require an slow writev() to fill zeros?  So you want to tell the
> > destination about the zeroes ASAP.
> 
> Sorry, missed this question. Yes. If a lot of zero blocks is queued it delays
> migration because the target is idle while the source is queuing zero blocks.

Thanks.  I think this makes sense.

Stefan