* Li, Liang Z (liang.z.li@intel.com) wrote:

quoted

On Mon, Mar 14, 2016 at 05:03:34PM +0000, Dr. David Alan Gilbert wrote:

quoted

* Li, Liang Z (liang.z.li@intel.com) wrote:

quoted

quoted

Hi,
  I'm just catching back up on this thread; so without reference
to any particular previous mail in the thread.

  1) How many of the free pages do we tell the host about?
     Your main change is telling the host about all the
     free pages.

Yes, all the guest's free pages.

quoted

     If we tell the host about all the free pages, then we might
     end up needing to allocate more pages and update the host
     with pages we now want to use; that would have to wait for the
     host to acknowledge that use of these pages, since if we don't
     wait for it then it might have skipped migrating a page we
     just started using (I don't understand how your series solves that).
     So the guest probably needs to keep some free pages - how many?

Actually, there is no need to care about whether the free pages will be

used by the host.

quoted

quoted

We only care about some of the free pages we get reused by the guest,

right?

quoted

quoted

The dirty page logging can be used to solve this, starting the dirty
page logging before getting the free pages informant from guest.
Even some of the free pages are modified by the guest during the
process of getting the free pages information, these modified pages will

be traced by the dirty page logging mechanism. So in the following
migration_bitmap_sync() function.

quoted

quoted

The pages in the free pages bitmap, but latter was modified, will be
reset to dirty. We won't omit any dirtied pages.

So, guest doesn't need to keep any free pages.

OK, yes, that works; so we do:
  * enable dirty logging
  * ask guest for free pages
  * initialise the migration bitmap as everything-free
  * then later we do the normal sync-dirty bitmap stuff and it all just works.

That's nice and simple.

This works once, sure. But there's an issue is that you have to defer migration
until you get the free page list, and this only works once. So you end up with
heuristics about how long to wait.

Instead I propose:

- mark all pages dirty as we do now.

- at start of migration, start tracking dirty
  pages in kvm, and tell guest to start tracking free pages

we can now introduce any kind of delay, for example wait for ack from guest,
or do whatever else, or even just start migrating pages

- repeatedly:
	- get list of free pages from guest
	- clear them in migration bitmap
	- get dirty list from kvm

- at end of migration, stop tracking writes in kvm,
  and tell guest to stop tracking free pages

I had thought of filtering out the free pages in each migration bitmap synchronization. 
The advantage is we can skip process as many free pages as possible. Not just once.
The disadvantage is that we should change the current memory management code to track the free pages,
instead of traversing the free page list to construct the free pages bitmap, to reduce the overhead to get the free pages bitmap.
I am not sure the if the Kernel people would like it.

If keeping the traversing mechanism, because of the overhead, maybe it's not worth to filter out the free pages repeatedly.

Well, Michael's idea of not waiting for the dirty
bitmap to be filled does make that idea of constnatly
using the free-bitmap better.

In that case, is it easier if something (guest/host?)
allocates some memory in the guests physical RAM space
and just points the host to it, rather than having an 
explicit 'send'.

Dave

Liang

--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK