Re: [PATCH kvm-unit-tests] pmu: fixes for Sandy Bridge hosts

[Gleb Natapov <gleb@redhat.com>]

On Mon, Jun 03, 2013 at 09:08:46AM +0200, Paolo Bonzini wrote:
> Il 03/06/2013 08:38, Gleb Natapov ha scritto:
> > On Mon, Jun 03, 2013 at 08:33:13AM +0200, Paolo Bonzini wrote:
> >> Il 02/06/2013 17:32, Gleb Natapov ha scritto:
> >>> On Thu, May 30, 2013 at 07:43:07PM +0200, Paolo Bonzini wrote:
> >>>> This patch includes two fixes for SB:
> >>>>
> >>>> * the 3rd fixed counter ("ref cpu cycles") can sometimes report
> >>>>   less than the number of iterations
> >>>>
> >>> Is it documented? It is strange for "architectural" counter to behave
> >>> differently on different architectures.
> >>
> >> It just counts the CPU cycles.  If the CPU can optimize the loop better,
> >> it will take less CPU cycles to execute it.
> >>
> > We should try and change the loop so that it will not be so easily optimized.
> > Making the test succeed if only 10% percent of cycles were spend on a loop
> > may result in the test missing the case when counter counts something
> > different.
> 
> Any hard-to-optimize loop risks becoming wrong on the other side (e.g.
> if something stalls the pipeline, a newer chip with longer pipeline will
> use more CPU cycles).
> 
> Turbo boost could also contribute to lowering the number of cycles; a
> boosted processor has ref cpu cycles that are _longer_ than the regular
> cycles (thus they count in smaller numbers).  Maybe that's why "core
> cycles" didn't go below N.
> 
"core cycles" are subject to Turbo boost changes, not ref cycles. Since
instruction are executed at core frequency ref cpu cycles count may be
indeed smaller.

> The real result was something like 0.8*N (780-830000).  I used 0.1*N
> because it is used for the "ref cpu cycles" gp counter, which is not the
> same but similar.  Should I change it to 0.5*N or so?
> 
For cpus with constant_tsc they should be the same. OK lets make gp and
fixed use the same boundaries.

--
			Gleb.