From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/4] KVM: Dirty logging optimization using rmap Date: Tue, 29 Nov 2011 16:03:18 +0200 Message-ID: <4ED4E626.5010507@redhat.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: Xiao Guangrong Return-path: Received: from mx1.redhat.com ([209.132.183.28]:21893 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752547Ab1K2ODu (ORCPT ); Tue, 29 Nov 2011 09:03:50 -0500 In-Reply-To: <4ED4C9A3.50504@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. -- error compiling committee.c: too many arguments to function