From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59065) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQIOw-0006Nk-Fa for qemu-devel@nongnu.org; Thu, 11 Apr 2013 10:23:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQIOq-00041w-Ib for qemu-devel@nongnu.org; Thu, 11 Apr 2013 10:22:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33726) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQIOq-00041a-7l for qemu-devel@nongnu.org; Thu, 11 Apr 2013 10:22:52 -0400 Message-ID: <5166C59A.4010904@redhat.com> Date: Thu, 11 Apr 2013 16:15:54 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <5166B9A9.9070904@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: "Michael R. Hines" Cc: aliguori@us.ibm.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com 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