From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53767) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zw6CD-0005Sj-Fg for qemu-devel@nongnu.org; Tue, 10 Nov 2015 05:30:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zw6CC-0004Mf-7e for qemu-devel@nongnu.org; Tue, 10 Nov 2015 05:30:37 -0500 References: <1446805353-3047-1-git-send-email-famz@redhat.com> <20151109160409.GC3621@noname.redhat.com> <5640C768.50704@redhat.com> <20151109162934.GL3621@noname.redhat.com> <20151110061458.GB26289@ad.usersys.redhat.com> <5641B282.10706@redhat.com> <20151110101259.GA4163@noname.redhat.com> From: Paolo Bonzini Message-ID: <5641C73D.8090008@redhat.com> Date: Tue, 10 Nov 2015 11:30:21 +0100 MIME-Version: 1.0 In-Reply-To: <20151110101259.GA4163@noname.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] mirror: Improve zero-write and discard with fragmented image List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Fam Zheng , qemu-devel@nongnu.org, qemu-block@nongnu.org On 10/11/2015 11:12, Kevin Wolf wrote: > > For full mirroring, this strategy will probably make the first > > incremental iteration more expensive. > > You mean because we issue smaller, interleaved write and write_zeroes > requests now instead of only large writes? That's probably right, but > getting the right result should be more important than speed. :-) No, because you might end up clearing the whole dirty bitmap before issuing the first bdrv_get_block_status_above(). Blocks are actually read much later; if someone sets the dirty bitmap in between, you will re-write those blocks unnecessarily during the first incremental iteration. It's not specific to the first iteration, it's just more likely. However, it may be enough to clamp the number of dirty bitmap bits that you process in one go (e.g. to 100 MB of so). Paolo