From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38314) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIPet-0005Zj-Qb for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:30:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIPel-0008Uk-LC for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:30:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIPel-0008UW-Ba for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:30:43 -0400 Date: Wed, 20 Mar 2013 22:31:19 +0200 From: "Michael S. Tsirkin" Message-ID: <20130320203119.GA23583@redhat.com> References: <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> <20130320190633.GB22631@redhat.com> <514A19F6.3020406@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <514A19F6.3020406@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 04:20:06PM -0400, Michael R. Hines wrote: > On 03/20/2013 03:06 PM, Michael S. Tsirkin wrote: > > 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. > > > Yes, absolutely: https://www.kernel.org/doc/Documentation/vm/pagemap.txt > > The pagemap will tell you that. > > In fact the pagemap ideally would *only* be used for the 1st migration round. > > The rest of them would depend exclusively on the dirty bitmap as they do. > > Basically, we could use the pagemap as first-time "hint" for the bulk of > the memory that costs the most to transmit. OK sure, this could be useful to detect pages deduplicated by KSM and only transmit one copy. There's still the question of creating same duplicate mappings on destination - do you just do data copy on destination? Not sure why you talk about unmapped pages above though, it seems not really relevant... There's also the matter of KSM not touching pinned pages, that's another good reason not to pin all pages on destination, they won't be deduplicated.