From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36519) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfHGJ-0006xp-9k for qemu-devel@nongnu.org; Thu, 14 Jun 2012 17:07:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SfHGH-0000KG-JL for qemu-devel@nongnu.org; Thu, 14 Jun 2012 17:07:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfHGH-0000Jx-AD for qemu-devel@nongnu.org; Thu, 14 Jun 2012 17:07:25 -0400 From: Juan Quintela In-Reply-To: <4FD1D2B1.2080108@redhat.com> (Avi Kivity's message of "Fri, 08 Jun 2012 13:23:45 +0300") References: <4FCCABF0.6080907@us.ibm.com> <87y5nyxg4q.fsf@elfo.mitica> <4FD1D2B1.2080108@redhat.com> Date: Thu, 14 Jun 2012 23:07:06 +0200 Message-ID: <87zk85siv9.fsf@elfo.mitica> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v2 00/41] postcopy live migration Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: benoit.hudzia@gmail.com, aarcange@redhat.com, Anthony Liguori , kvm@vger.kernel.org, owasserm@redhat.com, stefanha@gmail.com, t.hirofuchi@aist.go.jp, dlaor@redhat.com, satoshi.itoh@aist.go.jp, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com, yoshikawa.takuya@oss.ntt.co.jp, Isaku Yamahata , pbonzini@redhat.com Avi Kivity wrote: > On 06/08/2012 01:16 PM, Juan Quintela wrote: >> Anthony Liguori wrote: >> >> Once told that, we need to measure what is the time of an async page >> fault over the network. If it is too high, post copy just don't work. >> >> And no, I haven't seen any measurement that told us that this is going >> to be fast enough, but there is always hope. > > At 10Gb/sec, the time to transfer one page is 4 microseconds. At > 40Gb/sec this drops to a microsecond, plus the latency. This is on par > with the time to handle a write protection fault that precopy uses. But > this can *only* be achieved with RDMA, otherwise the overhead of > messaging and copying will dominate. > > Note this does not mean we should postpone merging until RDMA support is > ready. However we need to make sure the kernel interface is RDMA friendly. Fully agree here. I always thought that postcopy will work with RDMA or something like that, any other thing would just add too much latency. Later, Juan.