[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDC5CD5@SHSMSX102.ccr.corp.intel.com>
Date: Thu, 17 May 2012 06:30:45 +0000
From: "Hao, Xudong" <xudong.hao@...el.com>
To: Avi Kivity <avi@...hat.com>,
Takuya Yoshikawa <takuya.yoshikawa@...il.com>
CC: Xudong Hao <xudong.hao@...ux.intel.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Shan, Haitao" <haitao.shan@...el.com>,
"Zhang, Xiantao" <xiantao.zhang@...el.com>
Subject: RE: [PATCH 0/4] KVM: Enable EPT access bit feature
> -----Original Message-----
> From: Avi Kivity [mailto:avi@...hat.com]
> Sent: Wednesday, May 16, 2012 9:44 PM
> To: Takuya Yoshikawa
> Cc: Xudong Hao; kvm@...r.kernel.org; linux-kernel@...r.kernel.org; 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@...hat.com> 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists