From mboxrd@z Thu Jan  1 00:00:00 1970
From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Subject: Re: [PATCH 0/4] KVM: Dirty logging optimization using rmap
Date: Tue, 29 Nov 2011 19:56:10 +0800
Message-ID: <4ED4C85A.5020509@linux.vnet.ibm.com>
References: <20111114182041.43570cdf.yoshikawa.takuya@oss.ntt.co.jp> <4EC0EC90.1090202@redhat.com> <4EC0F3D3.9090907@oss.ntt.co.jp> <4EC10BFE.7050704@redhat.com> <4EC33C0B.1060807@oss.ntt.co.jp> <4EC37D18.4010609@redhat.com> <loom.20111129T104524-678@post.gmane.org> <4ED4AF43.2040003@linux.vnet.ibm.com> <4ED4B574.8090907@oss.ntt.co.jp> <4ED4BFEB.5010600@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	KVM <kvm@vger.kernel.org>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from e23smtp02.au.ibm.com ([202.81.31.144]:49769 "EHLO
	e23smtp02.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752817Ab1K2L4S (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 29 Nov 2011 06:56:18 -0500
Received: from /spool/local
	by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted
	for <kvm@vger.kernel.org> from <xiaoguangrong@linux.vnet.ibm.com>;
	Tue, 29 Nov 2011 11:42:30 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pATBqkg12080822
	for <kvm@vger.kernel.org>; Tue, 29 Nov 2011 22:52:46 +1100
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pATBuCEX009862
	for <kvm@vger.kernel.org>; Tue, 29 Nov 2011 22:56:13 +1100
In-Reply-To: <4ED4BFEB.5010600@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 11/29/2011 07:20 PM, Avi Kivity wrote:


> We used to have a bitmap in a shadow page with a bit set for every slot
> pointed to by the page.  If we extend this to non-leaf pages (so, when
> we set a bit, we propagate it through its parent_ptes list), then we do
> the following on write fault:
> 


Thanks for the detail.

Um, propagating slot bit to parent ptes is little slow, especially, it
is the overload for no Xwindow guests which is dirty logged only in the
migration(i guess most linux guests are running on this mode and migration
is not frequent). No?