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

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Apr 18, 2016 at 02:36:31PM +0000, Li, Liang Z wrote:
> > On Mon, Apr 18, 2016 at 11:08:31AM +0000, Li, Liang Z wrote:
> > > Hi Dave,
> > >
> > > I am now working on how to benefit post-copy by skipping the free
> > > pages, and I remember you have said we should let the destination know
> > > the info of free pages so as to avoid request the free pages from the
> > source.
> > >
> > > We have two solutions:
> > >
> > > a. send the migration dirty page bitmap to destination before post
> > > copy start, so the destination can decide whether to request the pages
> > > or place zero pages by checking the migration dirty page bitmap. The
> > > advantage is that we can avoid sending the free pages. the
> > > disadvantage is that we have to send extra data to destination.
> > >
> > > b. Check the page request on the source side, if it's not a dirty
> > > page, send a zero page header to the destination.
> > >
> > > What's your opinion about them?
> > >
> > > Liang
> > >
> > 
> > Both are ad-hoc solutions imho.
> > 
> > c. put the bitmap in a ramblock, check it on destination before
> >    requesting pages.
> > 
> > This way it's migrated on-demand.
> > 
> Hi MST,
> 
> I think you mean  putting the free page bitmap in a ramblock. Right?
> If some of the free pages become dirty after updating the free page bitmap,
> and these pages are discarded by destination, how can we distinguish these
> discarded pages with the free pages?
> 
> Could you elaborate how it works?
> 
> Thanks!
> Liang

Maybe I'm confused - IIUC it's postcopy so VM is running on destination,
if page is dirty it was modified there so we don't need to get it from
source.

But really I agree with David here - at step 1 just ignore postcopy,
don't special-case it, even if it becomes slower with your patch.
Think about it later.

> 
> 
> > --
> > MST
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in the body of
> > a message to majordomo@vger.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html