From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFNv7-0004u4-TN for qemu-devel@nongnu.org; Tue, 12 Mar 2013 08:03:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFNv1-0007mt-EA for qemu-devel@nongnu.org; Tue, 12 Mar 2013 08:03:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFNv1-0007mj-6w for qemu-devel@nongnu.org; Tue, 12 Mar 2013 08:02:59 -0400 Message-ID: <513F196A.5020509@redhat.com> Date: Tue, 12 Mar 2013 13:02:50 +0100 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <51C6C0ED-112B-4421-B00A-5CD701AC193D@dlhnet.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] optimize is_dup_page for zero pages List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: Kevin Wolf , Stefan Hajnoczi , Orit Wasserman , "qemu-devel@nongnu.org" , peter.maydell@linaro.org 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. :) > 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. 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