Re: [Qemu-devel] [PATCH] migration: not send zero page header in ram bulk stage

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

* Li, Liang Z (liang.z.li@intel.com) wrote:
> > * Liang Li (liang.z.li@intel.com) wrote:
> > > Now that VM's RAM pages are initialized to zero, (VM's RAM is allcated
> > > with the mmap() and MAP_ANONYMOUS option, or mmap() without
> > MAP_SHARED
> > > if hugetlbfs is used.) so there is no need to send the zero page
> > > header to destination.
> > >
> > > For guest just uses a small portions of RAM, this change can avoid
> > > allocating all the guest's RAM pages in the destination node after
> > > live migration. Another benefit is destination QEMU can save lots of
> > > CPU cycles for zero page checking.
> > 
> > I think this would break postcopy, because the zero pages wouldn't be filled
> > in, so accessing them would still generate a userfault.
> > So you'd have to disable this optimisation if postcopy is enabled (even during
> > the precopy bulk stage).
> > 
> > Also, are you sure about the benefits?
> >  Destination guests RAM should not be allocated on receiving a zero page;
> > see ram_handle_compressed, it doesn't write to the page if it's zero, so it
> > shouldn't cause an allocate.  I think you're probably correct about the zero
> > page test on the destination, I wonder if we can speed that up.
> > 
> > Dave
> 
> I have test the performance, with a 8G guest just booted, this patch can reduce total live migration time about 10%.
> Unfortunately, Paolo said this patch would break LM in some case ....
> 
> For the zero page test on the destination, if the page is really a zero page, test is faster than writing a whole page of zero.

There shouldn't be a write on the destination though; it does a check if
the page is already zero and only if it's none-zero does it do the write;
it should rarely be non-zero.

Dave

> 
> Liang
> 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK