From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52025) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCUy8-0003pZ-8z for qemu-devel@nongnu.org; Mon, 04 Mar 2013 07:58:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCUy2-0003TF-Sm for qemu-devel@nongnu.org; Mon, 04 Mar 2013 07:58:16 -0500 Received: from mail-bk0-f49.google.com ([209.85.214.49]:46776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCUy2-0003T5-M3 for qemu-devel@nongnu.org; Mon, 04 Mar 2013 07:58:10 -0500 Received: by mail-bk0-f49.google.com with SMTP id w11so2374740bku.8 for ; Mon, 04 Mar 2013 04:58:09 -0800 (PST) Date: Mon, 4 Mar 2013 13:58:06 +0100 From: Stefan Hajnoczi Message-ID: <20130304125806.GA18476@stefanha-thinkpad.redhat.com> References: <20130220142939.GF16633@stefanha-thinkpad.muc.redhat.com> <24E144B8C0207547AD09C467A8259F7557A6EFE2@lisa.maurer-it.com> <20130221130345.GD22957@stefanha-thinkpad.redhat.com> <24E144B8C0207547AD09C467A8259F7557A6FAAC@lisa.maurer-it.com> <20130222095736.GA6107@stefanha-thinkpad.redhat.com> <24E144B8C0207547AD09C467A8259F7557A70A61@lisa.maurer-it.com> <20130225134551.GE3202@stefanha-thinkpad.redhat.com> <24E144B8C0207547AD09C467A8259F7557AE0931@lisa.maurer-it.com> <20130228144920.GD18389@stefanha-thinkpad.redhat.com> <24E144B8C0207547AD09C467A8259F7557B12DDC@lisa.maurer-it.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24E144B8C0207547AD09C467A8259F7557B12DDC@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: "qemu-devel@nongnu.org" On Thu, Feb 28, 2013 at 03:24:27PM +0000, Dietmar Maurer wrote: > > > Unfortunately, NBD add considerable overheads. I guess the socket > > communications copies data. > > > This is really unnecessary if I can write directly to the output stream. > > > > The disk is the bottleneck, not memory bandwidth. Hard disks only do > > 10-100 MB/sec and SSDs only do a couple 100 MB/sec. Memory copy is > > insignificant compared to the I/O activity required to copy out the entire disk > > image, not to mention delaying guest writes until we read the original data from > > the disk. > > > > Unless there's a concrete performance problem here this is premature > > optimization. > > I currently test with about 700MB read speed, and get a slow down by factor 1.7. > So memory copy is very significant , or there is something wrong with nbd.c. What are the details of the test? Is it using 64 KB writes and have you tried 256 KB writes? Stefan