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