From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQImz-000887-Va for qemu-devel@nongnu.org; Thu, 11 Apr 2013 10:47:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQImw-0004rb-It for qemu-devel@nongnu.org; Thu, 11 Apr 2013 10:47:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQImw-0004p1-A5 for qemu-devel@nongnu.org; Thu, 11 Apr 2013 10:47:46 -0400 Date: Thu, 11 Apr 2013 17:45:34 +0300 From: "Michael S. Tsirkin" Message-ID: <20130411144534.GE24942@redhat.com> References: <1365632901-15470-1-git-send-email-mrhines@linux.vnet.ibm.com> <1365632901-15470-11-git-send-email-mrhines@linux.vnet.ibm.com> <20130411073843.GB19601@redhat.com> <51667FEE.903@redhat.com> <5166B9A9.9070904@linux.vnet.ibm.com> <5166C59A.4010904@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5166C59A.4010904@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v1: 10/13] introduce new command migrate_check_for_zero List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, "Michael R. Hines" , owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com On Thu, Apr 11, 2013 at 04:15:54PM +0200, Paolo Bonzini wrote: > Il 11/04/2013 15:24, Michael R. Hines ha scritto: > > That's very accurate. Zero page scanning *after* the bulk phase > > is not very helpful in general. > > > > Are we proposing to skip is_dup_page() after the bulk phase > > has finished? > > No, I'm saying that is_dup_page() should not be a problem. I'm saying > it should only loop a lot during the bulk phase. The only effect I can > imagine after the bulk phase is one cache miss. > > Perhaps the stress-test you're using does not reproduce realistic > conditions with respect to zero pages. Peter Lieven benchmarked real > guests, both Linux and Windows, and confirmed the theory that I > mentioned upthread. Almost all non-zero pages are detected within the > first few words, and almost all zero pages come from the bulk phase. > > Considering that one cache miss, RDMA is indeed different here. TCP > would have this cache miss later anyway, RDMA does not. Let's say 300 > cycles/miss; at 2.5 GHz that is 300/2500 microseconds, i.e 0.12 > microseconds per page. This would say that we can run is_dup_page on 30 > GB worth of nonzero pages every second or more. Ok, the estimate is > quite generous in many ways, but is_dup_page() is only a bottleneck if > it can do less than 5 GB/s. > > Paolo Further, if we read the pagemap to detect duplicates, we won't need to read the page for RDMA either. This might or might not prove to be a win, but one thing for sure, management will not be able to know if it's a win. -- MST