From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [PATCH 0/4] KVM: Dirty logging optimization using rmap Date: Wed, 30 Nov 2011 15:03:23 +0800 Message-ID: <4ED5D53B.2050305@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> <4ED4AF43.2040003@linux.vnet.ibm.com> <4ED4B574.8090907@oss.ntt.co.jp> <4ED4BFEB.5010600@redhat.com> <4ED4C85A.5020509@linux.vnet.ibm.com> <4ED4C9A3.50504@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Takuya Yoshikawa , Marcelo Tosatti , KVM To: Avi Kivity Return-path: Received: from e28smtp01.in.ibm.com ([122.248.162.1]:53535 "EHLO e28smtp01.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751522Ab1K3Hhr (ORCPT ); Wed, 30 Nov 2011 02:37:47 -0500 Received: from /spool/local by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 30 Nov 2011 12:34:13 +0530 Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pAU73PR84259844 for ; Wed, 30 Nov 2011 12:33:25 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pAU73OIw019037 for ; Wed, 30 Nov 2011 18:03:25 +1100 In-Reply-To: <4ED4C9A3.50504@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/29/2011 08:01 PM, Avi Kivity wrote: > On 11/29/2011 01:56 PM, Xiao Guangrong wrote: >> 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? > > You need to propagate very infrequently. The first pte added to a page > will need to propagate, but the second (if from the same slot, which is > likely) will already have the bit set in the page, so we're assured it's > set in all its parents. > What will happen if a guest page is unmapped or a shadow page is zapped? It should immediately clear the "slot" bit of the shadow page and its parent, it means it should propagate this "clear slot bit" event to all parents, in the case of softmmu. zapping shadow page is frequently, maybe it is unacceptable? It does not like "unsync" bit which can be lazily cleared, because all bits of hierarchy can be cleared when cr3 reload.