From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39610) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIPkr-0007nv-H6 for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:37:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIPko-0001ok-Oh for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:37:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIPko-0001od-GF for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:36:58 -0400 Date: Wed, 20 Mar 2013 22:37:34 +0200 From: "Michael S. Tsirkin" Message-ID: <20130320203734.GB23583@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> <514A1AEE.1070308@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <514A1AEE.1070308@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: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? > 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. > 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.