From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42154) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL5wz-0005to-VH for qemu-devel@nongnu.org; Mon, 18 Jan 2016 04:18:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aL5wv-0002tl-Sm for qemu-devel@nongnu.org; Mon, 18 Jan 2016 04:18:13 -0500 Received: from szxga02-in.huawei.com ([119.145.14.65]:19115) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL5wv-0002tZ-9P for qemu-devel@nongnu.org; Mon, 18 Jan 2016 04:18:09 -0500 References: <1452851297-11198-1-git-send-email-liang.z.li@intel.com> <20160115185707.GI2432@work-vm> From: Hailiang Zhang Message-ID: <569CADBB.1010102@huawei.com> Date: Mon, 18 Jan 2016 17:17:47 +0800 MIME-Version: 1.0 In-Reply-To: <20160115185707.GI2432@work-vm> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit 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: "Dr. David Alan Gilbert" , Liang Li Cc: amit.shah@redhat.com, pbonzini@redhat.com, quintela@redhat.com, peter.huangpeng@huawei.com, qemu-devel@nongnu.org On 2016/1/16 2:57, Dr. David Alan Gilbert 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. > Yes, we have already optimize the zero page allocation in destination. but this patch can reduce the amount of data that transferred and the time of checking zero page, which can reduce the migration time. > Dave > >> >> Signed-off-by: Liang Li >> --- >> migration/ram.c | 10 ++++++---- >> 1 file changed, 6 insertions(+), 4 deletions(-) >> >> diff --git a/migration/ram.c b/migration/ram.c >> index 4e606ab..c4821d1 100644 >> --- a/migration/ram.c >> +++ b/migration/ram.c >> @@ -705,10 +705,12 @@ static int save_zero_page(QEMUFile *f, RAMBlock *block, ram_addr_t offset, >> >> if (is_zero_range(p, TARGET_PAGE_SIZE)) { >> acct_info.dup_pages++; >> - *bytes_transferred += save_page_header(f, block, >> - offset | RAM_SAVE_FLAG_COMPRESS); >> - qemu_put_byte(f, 0); >> - *bytes_transferred += 1; >> + if (!ram_bulk_stage) { >> + *bytes_transferred += save_page_header(f, block, offset | >> + RAM_SAVE_FLAG_COMPRESS); >> + qemu_put_byte(f, 0); >> + *bytes_transferred += 1; >> + } >> pages = 1; >> } >> >> -- >> 1.9.1 >> > -- > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > > . >