From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47392) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeG6r-0006Z9-2K for qemu-devel@nongnu.org; Fri, 11 Mar 2016 00:59:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aeG6n-0002y6-2Q for qemu-devel@nongnu.org; Fri, 11 Mar 2016 00:59:37 -0500 Received: from g2t4619.austin.hp.com ([15.73.212.82]:42041) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeG6m-0002xz-TP for qemu-devel@nongnu.org; Fri, 11 Mar 2016 00:59:32 -0500 References: <1457082167-12254-1-git-send-email-jitendra.kolhe@hpe.com> <20160310094912.GC9715@rkaganb.sw.ru> From: Jitendra Kolhe Message-ID: <56E25EBF.6050109@hpe.com> Date: Fri, 11 Mar 2016 11:29:27 +0530 MIME-Version: 1.0 In-Reply-To: <20160310094912.GC9715@rkaganb.sw.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v1] migration: skip sending ram pages released by virtio-balloon driver. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Roman Kagan , qemu-devel@nongnu.org, dgilbert@redhat.com, simhan@hpe.com, mohan_parthasarathy@hpe.com On 3/10/2016 3:19 PM, Roman Kagan wrote: > On Fri, Mar 04, 2016 at 02:32:47PM +0530, Jitendra Kolhe wrote: >> Even though the pages which are returned to the host by virtio-balloon >> driver are zero pages, the migration algorithm will still end up >> scanning the entire page ram_find_and_save_block() -> ram_save_page/ >> ram_save_compressed_page -> save_zero_page() -> is_zero_range(). We >> also end-up sending some control information over network for these >> page during migration. This adds to total migration time. > > I wonder if it is the scanning for zeros or sending the whiteout which > affects the total migration time more. If it is the former (as I would > expect) then a rather local change to is_zero_range() to make use of the > mapping information before scanning would get you all the speedups > without protocol changes, interfering with postcopy etc. > > Roman. > Localizing the solution to zero page scan check is a good idea. I too agree that most of the time is send in scanning for zero page in which case we should be able to localize solution to is_zero_range(). However in case of ballooned out pages (which can be seen as a subset of guest zero pages) we also spend a very small portion of total migration time in sending the control information, which can be also avoided. From my tests for 16GB idle guest of which 12GB was ballooned out, the zero page scan time for 12GB ballooned out pages was ~1789 ms and save_page_header + qemu_put_byte(f, 0); for same 12GB ballooned out pages was ~556 ms. Total migration time was ~8000 ms 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; pages = 1; } Would moving the solution to save_zero_page() be good enough? Thanks, - Jitendra