quoted

quoted

quoted

quoted

quoted

  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?

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

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.

quoted

The advantage is we can skip process as many free pages as possible. Not

just once.

quoted

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.

quoted

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.

No wait is a good idea.
Actually, we could shorten the waiting time by pre allocating the free pages bit map
and update it when guest allocating/freeing pages. it requires to modify the mm 
related code. I don't know whether the kernel people like this.

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

Good idea too.

Liang

Dave