From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDWlr-0002er-Hs for qemu-devel@nongnu.org; Thu, 07 Mar 2013 04:05:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDWll-0002FR-DW for qemu-devel@nongnu.org; Thu, 07 Mar 2013 04:05:51 -0500 Received: from mail-ee0-f54.google.com ([74.125.83.54]:34715) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDWll-0002FL-7f for qemu-devel@nongnu.org; Thu, 07 Mar 2013 04:05:45 -0500 Received: by mail-ee0-f54.google.com with SMTP id c41so132119eek.13 for ; Thu, 07 Mar 2013 01:05:44 -0800 (PST) Date: Thu, 7 Mar 2013 10:05:41 +0100 From: Stefan Hajnoczi Message-ID: <20130307090541.GA13854@stefanha-thinkpad.redhat.com> References: <20130225134551.GE3202@stefanha-thinkpad.redhat.com> <24E144B8C0207547AD09C467A8259F7557AE0931@lisa.maurer-it.com> <20130228144920.GD18389@stefanha-thinkpad.redhat.com> <24E144B8C0207547AD09C467A8259F7557B12DDC@lisa.maurer-it.com> <20130304125806.GA18476@stefanha-thinkpad.redhat.com> <24E144B8C0207547AD09C467A8259F7557B277AE@lisa.maurer-it.com> <20130304135537.GC3929@dhcp-200-207.str.redhat.com> <24E144B8C0207547AD09C467A8259F7557B278C1@lisa.maurer-it.com> <20130306124424.GE1954@stefanha-thinkpad.muc.redhat.com> <24E144B8C0207547AD09C467A8259F7557B2C525@lisa.maurer-it.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24E144B8C0207547AD09C467A8259F7557B2C525@lisa.maurer-it.com> Subject: Re: [Qemu-devel] [PATCH v4 3/6] add backup related monitor commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dietmar Maurer Cc: Kevin Wolf , "qemu-devel@nongnu.org" On Wed, Mar 06, 2013 at 02:42:57PM +0000, Dietmar Maurer wrote: > > > > Maybe you'd better use a different output format that doesn't > > > > restrict you to 64k writes. > > > > > > The output format is not really the restriction. The problem is that > > > an additional IPC layer add overhead, an d I do not want that (because it is > > totally unnecessary). > > > > I missed the reason why you cannot increase the block size. > > When we run backup, we need to read such block on every write from the guest. > So if we increase block size we get additional delays. Don't increase the bitmap block size. Just let the block job do larger reads. This is the bulk of the I/O workload. You can use large reads here independently of the bitmap block size. That way guest writes still only have a 64 KB read overhead but you reduce the overhead of doing so many 64 KB writes from the backup block job. Stefan