* Li, Liang Z (liang.z...@intel.com) wrote: > > * Liang Li (liang.z...@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 / dgilb...@redhat.com / Manchester, UK
