From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrPhg-0001go-UY for qemu-devel@nongnu.org; Tue, 25 Jun 2013 05:38:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrPhc-0006jd-9H for qemu-devel@nongnu.org; Tue, 25 Jun 2013 05:38:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrPcm-00058Q-Vz for qemu-devel@nongnu.org; Tue, 25 Jun 2013 05:33:21 -0400 From: Juan Quintela In-Reply-To: <1372125485-11795-11-git-send-email-mrhines@linux.vnet.ibm.com> (mrhines@linux.vnet.ibm.com's message of "Mon, 24 Jun 2013 21:58:00 -0400") References: <1372125485-11795-1-git-send-email-mrhines@linux.vnet.ibm.com> <1372125485-11795-11-git-send-email-mrhines@linux.vnet.ibm.com> Date: Tue, 25 Jun 2013 11:33:15 +0200 Message-ID: <87ehbq1qn8.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v11 10/15] rdma: introduce capability x-rdma-pin-all Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mrhines@linux.vnet.ibm.com Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com, pbonzini@redhat.com, chegu_vinod@hp.com, knoel@redhat.com mrhines@linux.vnet.ibm.com wrote: > From: "Michael R. Hines" > > This capability allows you to disable dynamic chunk registration > for better throughput on high-performance links. > > For example, using an 8GB RAM virtual machine with all 8GB of memory in > active use and the VM itself is completely idle using a 40 gbps infiniband link: > > 1. x-rdma-pin-all disabled total time: approximately 7.5 seconds @ 9.5 Gbps > 2. x-rdma-pin-all enabled total time: approximately 4 seconds @ 26 Gbps > > These numbers would of course scale up to whatever size virtual machine > you have to migrate using RDMA. > > Enabling this feature does *not* have any measurable affect on > migration *downtime*. This is because, without this feature, all of the > memory will have already been registered already in advance during > the bulk round and does not need to be re-registered during the successive > iteration rounds. > > Reviewed-by: Paolo Bonzini > Reviewed-by: Chegu Vinod > Reviewed-by: Eric Blake > Tested-by: Chegu Vinod > Tested-by: Michael R. Hines > Signed-off-by: Michael R. Hines Reviewed-by: Juan Quintela