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: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.