Re: [PATCH 0/4] KVM: Enable EPT access bit feature

[Avi Kivity]

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.

> 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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/