From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL6Bt-0004tZ-SZ for qemu-devel@nongnu.org; Mon, 18 Jan 2016 04:33:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aL6Bq-0007Iq-KB for qemu-devel@nongnu.org; Mon, 18 Jan 2016 04:33:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35736) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL6Bq-0007Il-Eu for qemu-devel@nongnu.org; Mon, 18 Jan 2016 04:33:34 -0500 Date: Mon, 18 Jan 2016 09:33:28 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20160118093328.GA2399@work-vm> References: <1452851297-11198-1-git-send-email-liang.z.li@intel.com> <20160115185707.GI2432@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] migration: not send zero page header in ram bulk stage List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Li, Liang Z" Cc: "amit.shah@redhat.com" , "pbonzini@redhat.com" , "zhang.zhanghailiang@huawei.com" , "qemu-devel@nongnu.org" , "quintela@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