Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature

["Hao, Xudong" <xudong.hao@xxxxxxxxx>]

> -----Original Message-----
> From: dunlapg@xxxxxxxxx [mailto:dunlapg@xxxxxxxxx] On Behalf Of George
> Dunlap
> Sent: Thursday, June 28, 2012 8:15 PM
> To: Hao, Xudong
> Cc: Tim Deegan; keir@xxxxxxx; Shan, Haitao; JBeulich@xxxxxxxx; Zhang,
> Xiantao; xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
> 
> On Tue, Jun 26, 2012 at 6:31 AM, Hao, Xudong <xudong.hao@xxxxxxxxx>
> wrote:
> >> -----Original Message-----
> >> From: Tim Deegan [mailto:tim@xxxxxxx]
> >> Sent: Monday, June 25, 2012 5:02 PM
> >> To: Hao, Xudong
> >> Cc: xen-devel@xxxxxxxxxxxxx; Shan, Haitao; keir@xxxxxxx; Zhang, Xiantao;
> >> JBeulich@xxxxxxxx
> >> Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
> >>
> >> At 09:57 +0800 on 20 Jun (1340186263), Xudong Hao wrote:
> >> > Changes from v1:
> >> > - Move hap_has_dirty_bit and hap_has_access_bit definition from patch 3
> to
> >> patch2.
> >> > - define them as bool_t instead of int.
> >> >
> >> > Extended Page Tables introduce two bit: access bit and dirty bit, A/D 
> >> > bits
> >> > enable VMMs to efficiently implement memory management and page
> >> classification
> >> > algorithms to optimize VM memory operations.
> >> >
> >> > This series of patches enable EPT dirty bit feature for guest live 
> >> > migration.
> >>
> >> Thanks for this.  I have a few high-level questions:
> >>
> >> - You're proposing this for after 4.2, right?
> >>
> >
> > Yes, they are not targeted to 4.2.
> >
> >> - Have you measured what difference this makes?  I take it it improves
> >>   performance during live migration but it would be good to know how
> much
> >>   before taking on extra code.
> >>
> >
> > We did live migration performance testing with patches, it's embarrassed to
> say but the result show there is no performance gain and no performance loss
> indeed.
> 
> What exactly did you measure?  If you measured the speed of the
> migration itself on an empty system, it might not be noticeable; but
> if, for instance, it increased the performance of a workload running
> *inside* the guest during the migration, 

Measured both idle guest and w/workload(specjbb) running guest migration.

> or if it decreased the cpu
> usage of qemu during the migraiton, that might be worth it.
> 

Thanks this point, will look at if cpu usage decreasing.

>  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel