> -----Original Message----- > From: Avi Kivity [mailto:avi@xxxxxxxxxx] > Sent: Wednesday, May 16, 2012 9:44 PM > To: Takuya Yoshikawa > Cc: Xudong Hao; kvm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Shan, > Haitao; Zhang, Xiantao; Hao, Xudong > Subject: Re: [PATCH 0/4] KVM: Enable EPT access bit feature > > On 05/16/2012 04:35 PM, Takuya Yoshikawa wrote: > > On Wed, 16 May 2012 12:21:53 +0300 > > Avi Kivity <avi@xxxxxxxxxx> wrote: > > > > > On 05/16/2012 04:04 AM, Xudong Hao wrote: > > > > EPT A/D bits enable VMMs to efficiently implement memory management > and page classification algorithms to optimize VM memory operations such as > de-fragmentation, paging, live-migration, and check-pointing. > > > > > > > > The series of patches enable the EPT access bit in KVM. > > > > > > > > PATCH 1: Add EPT A/D bits definition. > > > > PATCH 2: Add kernel parameter to control EPT A/D bits support, the > feature is on by default. > > > > PATCH 3: Enable EPT A/D bits if supported by turning on relevant bit in > EPTP. > > > > PATCH 4: Enabling Access bit when doing memory swapping. > > > > > > > > > > Minor comment on patch 2, but otherwise looks good. > > > > Except for being white space damaged and based on old kvm.git? > > Ugh, I didn't notice that. Xudong, please rebase on kvm.git 'next', and > repost using git send-email. > Oh, my patch is based on 'master' branch, I saw some changes in mmu.c by Takuya which will conflict patch 4, I'll rebase on 'next' branch. Anyway, I'll send whole four patches as v2 of 'next' branch. > > BTW, we can use this for dirty logging as you suggested. > > > > Although we need to traverse each spte from rmap > > That should be cheap. Also, we might be able to cheat for direct-mapped > pages: if all pages in a 2M area are mapped just once, in a > direct-mapped page, we can skip rmap and iterate over the page > directly. We can store this hint in lpage_info. > > There's a chance that this optimization will gain nothing since the > processor may be able to unroll the loop and hide the rmap costs for the > next spte behind the atomic access cost for the current spte. > > > and sync with dirty > > bitmap, I think it will work well by using with range based GET_DIRTY_LOG > > to restrict the cost for one call. > > I'm in favour of that as well (even more, since the install base will be > dominated by non-AD-capable hosts for some time). > > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
