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.
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.
--
error compiling committee.c: too many arguments to function
On Wed, 16 May 2012 12:21:53 +0300
Avi Kivity <[email protected]> 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?
BTW, we can use this for dirty logging as you suggested.
Although we need to traverse each spte from rmap 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.
Thanks,
Takuya
On 05/16/2012 04:35 PM, Takuya Yoshikawa wrote:
> On Wed, 16 May 2012 12:21:53 +0300
> Avi Kivity <[email protected]> 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
> -----Original Message-----
> From: Avi Kivity [mailto:[email protected]]
> Sent: Wednesday, May 16, 2012 9:44 PM
> To: Takuya Yoshikawa
> Cc: Xudong Hao; [email protected]; [email protected]; 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 <[email protected]> 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