From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44038) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIPyj-0006Ji-KN for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:51:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIPyd-0006nQ-Uh for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:51:21 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:52047) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIPsk-0004nd-O0 for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:45:10 -0400 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Mar 2013 14:45:09 -0600 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id CC608C90049 for ; Wed, 20 Mar 2013 16:45:05 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2KKj5Wx252910 for ; Wed, 20 Mar 2013 16:45:05 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2KKj5Wr021575 for ; Wed, 20 Mar 2013 17:45:05 -0300 Message-ID: <514A1FD1.9020000@linux.vnet.ibm.com> Date: Wed, 20 Mar 2013 16:45:05 -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> <514A1AEE.1070308@linux.vnet.ibm.com> <20130320203734.GB23583@redhat.com> In-Reply-To: <20130320203734.GB23583@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 On 03/20/2013 04:37 PM, Michael S. Tsirkin wrote: > On Wed, Mar 20, 2013 at 04:24:14PM -0400, Michael R. Hines wrote: >> On 03/20/2013 11:55 AM, Michael S. Tsirkin wrote: >>> 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? >>> >> Three scenarios are candidates for mapped checking: >> >> 1. anytime the virtual machine has not yet accessed a page (usually >> during the 1st-time boot) > So migrating booting machines is faster now? Why is this worth > optimizing for? Yes, it helps both the TCP migration and RDMA migration simultaneously. > >> 2. Anytime madvise(DONTNEED) happens (for ballooning) > This is likely worth optimizing. > I think a better the way to handling this one is by tracking > ballooned state. Just mark these pages as unused in qemu. Paolo said somebody attempted that, but stopped work on it for some reason? >> 3. Anytime cgroups kicks out a zero page that was accessed and >> faulted but not dirty that is a clean candidate for unmapping. >> (I did a test that seems to confirm that cgroups is pretty >> "smart" about that) >> Basically, anytime the pagemap says "this page is *not* swap and >> *not* mapped >> - then the page is not important during the 1st iteration. >> On the subsequent iterations, we come along as normal checking the >> dirty bitmap as usual. >> >> - Michael > If it will never be dirty you will never migrate it? > Seems wrong - it could have guest data on disk - AFAIK clean does not > mean no data, it means disk is in sync with memory. > Sorry, yes - that was a mis-statement: clean pages are always mapped (or swapped) and would have to be transmitted at least once. - Michael