qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Li, Liang Z
Subject: Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages
Date: Thu, 24 Mar 2016 14:50:56 +0000

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

As you described, the order is incorrect.

Liang

> Dave
> 
> >
> > Liang
> > >
> > > >
> > > > >Liang
> --
> Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]