From patchwork Tue Mar 12 12:15:13 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Lieven X-Patchwork-Id: 227011 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 073412C02ED for ; Tue, 12 Mar 2013 23:15:46 +1100 (EST) Received: from localhost ([::1]:59508 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFO7L-0001Ea-Te for incoming@patchwork.ozlabs.org; Tue, 12 Mar 2013 08:15:43 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49163) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFO6y-00010x-0H for qemu-devel@nongnu.org; Tue, 12 Mar 2013 08:15:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFO6t-0003eA-Id for qemu-devel@nongnu.org; Tue, 12 Mar 2013 08:15:19 -0400 Received: from ssl.dlhnet.de ([91.198.192.8]:44334 helo=ssl.dlh.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFO6t-0003dv-Cg for qemu-devel@nongnu.org; Tue, 12 Mar 2013 08:15:15 -0400 Received: from localhost (localhost [127.0.0.1]) by ssl.dlh.net (Postfix) with ESMTP id 0AF9D144081; Tue, 12 Mar 2013 13:15:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at ssl.dlh.net Received: from ssl.dlh.net ([127.0.0.1]) by localhost (ssl.dlh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4J5eqn2XOEo; Tue, 12 Mar 2013 13:15:13 +0100 (CET) Received: from lieven-mac.kamp-intra.net (unknown [82.141.1.207]) by ssl.dlh.net (Postfix) with ESMTPSA id A9FA013F93E; Tue, 12 Mar 2013 13:15:13 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Peter Lieven In-Reply-To: <513F196A.5020509@redhat.com> Date: Tue, 12 Mar 2013 13:15:13 +0100 Message-Id: <35D32F2E-08C9-4CDC-9636-E8DE47A2A50C@dlhnet.de> References: <513F08BF.4040209@dlhnet.de> <513F0D7E.4010901@redhat.com> <7E550AE8-25FC-4765-B75E-18DE70728616@dlhnet.de> <513F157F.2010000@redhat.com> <51C6C0ED-112B-4421-B00A-5CD701AC193D@dlhnet.de> <513F196A.5020509@redhat.com> To: Paolo Bonzini X-Mailer: Apple Mail (2.1499) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 91.198.192.8 Cc: Kevin Wolf , Stefan Hajnoczi , Orit Wasserman , "qemu-devel@nongnu.org" , peter.maydell@linaro.org Subject: Re: [Qemu-devel] [RFC] optimize is_dup_page for zero pages X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Am 12.03.2013 um 13:02 schrieb Paolo Bonzini : > Il 12/03/2013 12:51, Peter Lieven ha scritto: >>>> buffer_is_zero is used in somewhat special cases (block >>>> streaming/copy-on-read) where throughput doesn't really matter, unlike >>>> is_dup_page/find_zero_bit which are used in migration. But you can use >>>> similar code for is_dup_page and buffer_is_zero. >> ok, i will prepare a patch series for review. at the moment without touching >> is_dup_page(). you can decide later if you use buffer_Is_zero to check >> for zero pages later (maybe if the first x-bit are zero). >> >> Two comments on changing is_dup_page() to is_zero_page(): >> a) Would it make sense to only check for zero pages in the first (bulk) round? > > Interesting idea. Benchmark it. :) What approach would you use to test it? It again depends on the load. If there is no software running on the VM that is zeroing out large areas of memory I would bet there is no need looking for dup pages. > >> b) Would it make sense to not transfer zero pages at all in the first round? > > Perhaps yes, but I'm not sure how to efficiently implement it. There > really isn't a well-specified first round in the RAM migration code. Of > course you could have another bitmap for known-zero pages. what about this I used to limit XBZRLE to non-bulk stage: Peter > > But zero pages should be rare in real-world testcases, except for > ballooned pages. The OS should try to use free memory for caches. > >> The memory at the target should read as zero (not allocated) anyway. > > Paolo diff --git a/arch_init.c b/arch_init.c index 1b71912..d48b914 100644 --- a/arch_init.c +++ b/arch_init.c @@ -326,6 +326,7 @@ static ram_addr_t last_offset; static unsigned long *migration_bitmap; static uint64_t migration_dirty_pages; static uint32_t last_version; +static bool ram_bulk_stage; static inline ram_addr_t migration_bitmap_find_and_reset_dirty(MemoryRegion *mr, @@ -433,6 +434,7 @@ static int ram_save_block(QEMUFile *f, bool last_stage) if (!block) { block = QTAILQ_FIRST(&ram_list.blocks); complete_round = true; + ram_bulk_stage = false; } } else { uint8_t *p; @@ -536,6 +538,7 @@ static void reset_ram_globals(void) last_sent_block = NULL; last_offset = 0; last_version = ram_list.version; + ram_bulk_stage = true; } #define MAX_WAIT 50 /* ms, half buffered_file limit */