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:10:30 +0800 Message-ID: <4ED5D6E6.4070201@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> <4ED4E626.5010507@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 e28smtp03.in.ibm.com ([122.248.162.3]:45510 "EHLO e28smtp03.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756056Ab1K3HvG (ORCPT ); Wed, 30 Nov 2011 02:51:06 -0500 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 30 Nov 2011 12:42:58 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pAU7AWJe4837594 for ; Wed, 30 Nov 2011 12:40:32 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pAU7AWkF003222 for ; Wed, 30 Nov 2011 18:10:32 +1100 In-Reply-To: <4ED4E626.5010507@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/29/2011 10:03 PM, Avi Kivity wrote: > On 11/29/2011 02: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. > > btw, if you plan to work on this, let's agree on pseudocode/data > structures first to minimize churn. I'll also want this documented in > mmu.txt. Of course we can still end up with something different than > planned, but let's at least try to think of the issues in advance. > Yeap, this work is interesting, i will keep researching it. ;)