From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1O6LnA-0003FJ-1F
	for qemu-devel@nongnu.org; Mon, 26 Apr 2010 06:43:56 -0400
Received: from [140.186.70.92] (port=60930 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1O6Ln6-0003EX-IK
	for qemu-devel@nongnu.org; Mon, 26 Apr 2010 06:43:55 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <tamura.yoshiaki@lab.ntt.co.jp>) id 1O6Ln4-00054m-U6
	for qemu-devel@nongnu.org; Mon, 26 Apr 2010 06:43:52 -0400
Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]:54391)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <tamura.yoshiaki@lab.ntt.co.jp>) id 1O6Ln4-00054T-CQ
	for qemu-devel@nongnu.org; Mon, 26 Apr 2010 06:43:50 -0400
Message-ID: <4BD56E62.2040604@lab.ntt.co.jp>
Date: Mon, 26 Apr 2010 19:43:46 +0900
From: Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
MIME-Version: 1.0
References: <1271734843-24231-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp>
	<4BCEEC6E.6060103@redhat.com>
In-Reply-To: <4BCEEC6E.6060103@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: [Qemu-devel] Re: [PATCH v4 0/4] Introduce bit-based phys_ram_dirty,
 and bit-based dirty page checker.
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: aliguori@us.ibm.com, mtosatti@redhat.com, qemu-devel@nongnu.org, ohmura.kei@lab.ntt.co.jp

Hi,

Here are some numbers on bit-based phys_ram_dirty.

Test Environment:
CPU: 4x Intel Xeon Quad Core 2.66GHz
Mem size: 96GB

Host OS: CentOS (kernel 2.6.33)
Guest OS: Debian/GNU Linux lenny (kernel 2.6.26)
Guest Mem size: 512MB

Conditions of experiments are as follows:
Cond1: Guest OS periodically makes the 256MB continuous dirty pages.
Cond2: Guest OS periodically makes the 256MB dirty pages and non-dirty pa=
ges
in turn.
Cond3: Guest OS read 1GB file, which is bigger than memory.
Cond4: Guest OS write 1GB file, which is bigger than memory.

Experimental results:
Cond1: 5 =EF=BD=9E 83 times speed up
Cond2: 5 =EF=BD=9E 52 times speed up
Cond3: 5 =EF=BD=9E 132 times speed up
Cond4: 5 =EF=BD=9E 57 times speed up

The speed up grows when the number of rows, whose contents are 0, gets la=
rger.

Thanks,

Yoshi

Avi Kivity wrote:
> On 04/20/2010 06:40 AM, Yoshiaki Tamura wrote:
>> The dirty and non-dirty pages are checked one by one. When most of the
>> memory
>> is not dirty, checking the dirty and non-dirty pages by multiple page
>> size
>> should be much faster than checking them one by one. We introduced
>> bit-based
>> phys_ram_dirty for VGA, CODE, MIGRATION, MASTER, and
>> cpu_physical_memory_get_dirty_range() for this purpose.
>
> Looks good.
>