From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIPz9-0006h3-JK for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:51:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIPz6-0006w0-QA for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:51:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33527) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIPz6-0006vk-Hy for qemu-devel@nongnu.org; Wed, 20 Mar 2013 16:51:44 -0400 Date: Wed, 20 Mar 2013 22:52:21 +0200 From: "Michael S. Tsirkin" Message-ID: <20130320205221.GD23583@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> <514A1AEE.1070308@linux.vnet.ibm.com> <20130320203734.GB23583@redhat.com> <514A1FD1.9020000@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <514A1FD1.9020000@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:45:05PM -0400, Michael R. Hines wrote: > 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. But for a class of VMs that is only common when you want to run a benchmark. People do live migration precisely to avoid the need to reboot the VM. > > > >>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 Right so maybe my idea of looking at the PFNs in pagemap and transmitting only once could help some VMs (and it would cover the booting VMs as a partial case), and it could be a useful though linux-specific optimization, but I don't see how looking at whether page is mapped would help for TCP. -- MST