Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Li, Liang Z (liang.z.li@intel.com) wrote:
> > * Wei Yang (richard.weiyang@huawei.com) 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@redhat.com / Manchester, UK