From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35165) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIPUu-0001I3-93 for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:20:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIPUo-0004DL-PH for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:20:32 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:52078) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIPUo-0004Ch-Kh for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:20:26 -0400 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Mar 2013 16:20:22 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 45DCB38C80BA for ; Wed, 20 Mar 2013 16:20:13 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2KKKBSZ150554 for ; Wed, 20 Mar 2013 16:20:12 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2KKKBZG020364 for ; Wed, 20 Mar 2013 17:20:11 -0300 Message-ID: <514A19F6.3020406@linux.vnet.ibm.com> Date: Wed, 20 Mar 2013 16:20:06 -0400 From: "Michael R. Hines" MIME-Version: 1.0 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> <20130320190633.GB22631@redhat.com> In-Reply-To: <20130320190633.GB22631@redhat.com> Content-Type: multipart/alternative; boundary="------------050301010705080201090100" 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 S. Tsirkin" 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 This is a multi-part message in MIME format. --------------050301010705080201090100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. --------------050301010705080201090100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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.
--------------050301010705080201090100--