Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport

[Michael S. Tsirkin]

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