From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIOKp-0002H3-Nd for qemu-devel@nongnu.org; Wed, 20 Mar 2013 15:06:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIOKm-0005L5-K1 for qemu-devel@nongnu.org; Wed, 20 Mar 2013 15:06:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34331) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIOKm-0005Ki-AX for qemu-devel@nongnu.org; Wed, 20 Mar 2013 15:06:00 -0400 Date: Wed, 20 Mar 2013 21:06:34 +0200 From: "Michael S. Tsirkin" Message-ID: <20130320190633.GB22631@redhat.com> References: <51488521.4010909@linux.vnet.ibm.com> <20130319153658.GA14317@redhat.com> <51489BC3.3030504@linux.vnet.ibm.com> <51489D05.2000400@redhat.com> <5148A2F6.1070206@linux.vnet.ibm.com> <5148A5FB.1000209@redhat.com> <20130320130754.GA9777@redhat.com> <5149D2A4.2070106@linux.vnet.ibm.com> <20130320155514.GA20701@redhat.com> <5149DF08.4090209@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5149DF08.4090209@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael R. Hines" Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com, Paolo Bonzini On Wed, Mar 20, 2013 at 12:08:40PM -0400, Michael R. Hines wrote: > > On 03/20/2013 11:55 AM, Michael S. Tsirkin wrote: > >On Wed, Mar 20, 2013 at 11:15:48AM -0400, Michael R. Hines wrote: > >>OK, can we make a deal? =) > >> > >>I'm willing to put in the work to perform the dynamic registration > >>on the destination side, > >>but let's go a step further and piggy-back on the effort: > >> > >>We need to couple this registration with a very small modification > >>to save_ram_block(): > >> > >>Currently, save_ram_block does: > >> > >>1. is RDMA turned on? if yes, unconditionally add to next chunk > >> (will be made to > >>dynamically register on destination) > >>2. is_dup_page() ? if yes, skip > >>3. in xbzrle cache? if yes, skip > >>4. still not sent? if yes, transmit > >> > >>I propose adding a "stub" function that adds: > >> > >>0. is page mapped? if yes, skip (always returns true for now) > >>1. same > >>2. same > >>3. same > >>4. same > >> > >>Then, later, in a separate patch, I can implement /dev/pagemap support. > >> > >>When that's done, RDMA dynamic registration will actually take effect and > >>benefit from actually verifying that the page is mapped or not. > >> > >>- Michael > >Mapped into guest? You mean e.g. for ballooning? > > > > No, not just ballooning. Overcommit (i.e. cgroups). > > Anytime cgroups kicks out a page (or anytime the balloon kicks in), > the page would become unmapped. OK but we still need to send that page to remote. It's in swap but has guest data in there, you can't just ignore it. > The make dynamic registration useful, we have to actually have something > in place in the future that knows how to *check* if a page is unmapped > from the virtual machine, either because it has never been dirtied before > (and might be pointing to the zero page) or because it has been madvised() > out or has been detatched because of a cgroup limit. > > - Michael >