* Li, Liang Z (liang.z.li@xxxxxxxxx) wrote:
> > * Wei Yang (richard.weiyang@xxxxxxxxxx) wrote:
> > > On Wed, Mar 23, 2016 at 06:48:22AM +0000, Li, Liang Z wrote:
> > > [...]
> > > >> > 8. Pseudo code
> > > >> > Dirty page logging should be enabled before getting the free page
> > > >> > information from guest, this is important because during the
> > > >> > process of getting free pages, some free pages may be used and
> > > >> > written by the guest, dirty page logging can trace these pages.
> > > >> > The pseudo code is like below:
> > > >> >
> > > >> > -----------------------------------------------
> > > >> > MigrationState *s = migrate_get_current();
> > > >> > ...
> > > >> >
> > > >> > memory_global_dirty_log_start();
> > > >> >
> > > >> > if (get_guest_mem_info(&info)) {
> > > >> > while (!get_free_page_bmap(free_page_bitmap,
> > > >> > drop_page_cache)
> > > >> &&
> > > >> > s->state != MIGRATION_STATUS_CANCELLING) {
> > > >> > usleep(1000) // sleep for 1 ms
> > > >> > }
> > > >> >
> > > >> > tighten_free_page_bmap =
> > > >> tighten_guest_free_pages(free_page_bitmap);
> > > >> > filter_out_guest_free_pages(tighten_free_page_bmap);
> > > >> > }
> > > >>
> > > >> Given the typical speed of networks; it wouldn't do too much harm
> > > >> to start sending assuming all pages are dirty and then when the
> > > >> guest finally gets around to finishing the bitmap then update, so
> > > >> it's asynchronous - and then if the guest never responds we don't really
> > care.
> > > >
> > > >Indeed, thanks!
> > > >
> > >
> > > This is interesting. By doing so, the threshold I mentioned in another
> > > mail is not necessary, since we can do it in parallel.
> >
> > Actually I just realised it's a little more complex; we can't sync the dirty
> > bitmap again from the guest until after we've received the guests 'free'
> > bitmap; that's because we wouldn't know if a 'dirty' page reflected that a
> > page declared as 'free' had now been reused - so there is still an ordering
> > there.
> >
> > Dave
>
> Not very complex, we can implement like this:
>
> 1. Set all the bits in the migration_bitmap_rcu->bmap to 1
> 2. Clear all the bits in ram_list. dirty_memory[DIRTY_MEMORY_MIGRATION]
> 3. Send the get_free_page_bitmap request
> 4. Start to send pages to destination and check if the free_page_bitmap is ready
> if (is_ready) {
> filter out the free pages from migration_bitmap_rcu->bmap;
> migration_bitmap_sync();
> }
> continue until live migration complete.
>
>
> Is that right?
The order I'm trying to understand is something like:
a) Send the get_free_page_bitmap request
b) Start sending pages
c) Reach the end of memory
[ is_ready is false - guest hasn't made free map yet ]
d) normal migration_bitmap_sync() at end of first pass
e) Carry on sending dirty pages
f) is_ready is true
f.1) filter out free pages?
f.2) migration_bitmap_sync()
It's f.1 I'm worried about. If the guest started generating the
free bitmap before (d), then a page marked as 'free' in f.1
might have become dirty before (d) and so (f.2) doesn't set
the dirty again, and so we can't filter out pages in f.1.
Dave
>
> Liang
> >
> > >
> > > >Liang
--
Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
