Re: [PATCH v2 00/11] KVM in-guest performance monitoring

[Avi Kivity <avi@redhat.com>]

On 06/15/2011 07:51 PM, David Ahern wrote:
> The qemu-kvm change is setting the pmu version to 1, and your patchset
> introduces v1 event constraints. So based on intel_pmu_init model=0 is
> an appropriate model - and a required parameter (-cpu host,model=0).
> With that option I get the<not supported>  label as expected.
>
> Guest side:
>   Performance counter stats for 'openssl speed aes':
>
>        45160.015949 task-clock                #    0.998 CPUs utilized
>
>                 192 context-switches          #    0.000 M/sec
>
>                   0 CPU-migrations            #    0.000 M/sec
>
>                 650 page-faults               #    0.000 M/sec
>
>      57,064,592,321 cycles                    #    1.264 GHz
>          [49.96%]
>     138,608,368,094 instructions              #    2.43  insns per cycle
>          [50.04%]
>       3,003,337,751 branches                  #   66.504 M/sec
>          [50.04%]
>          21,890,537 branch-misses             #    0.73% of all branches
>          [49.96%]
>
>        45.242117218 seconds time elapsed
>
> (<not supported>  events removed). And comparable events from running the
> same command host side:
>   Performance counter stats for 'openssl speed aes':
>
>        44947.093539 task-clock                #    0.998 CPUs utilized
>
>               4,800 context-switches          #    0.000 M/sec
>
>                   5 CPU-migrations            #    0.000 M/sec
>
>                 481 page-faults               #    0.000 M/sec
>
>     124,610,137,228 cycles                    #    2.772 GHz
>          [27.77%]
>     338,982,292,106 instructions              #    2.72  insns per cycle
>
>       6,061,899,079 branches                  #  134.867 M/sec
>          [33.33%]
>           2,236,965 branch-misses             #    0.04% of all branches
>          [33.33%]
>        45.043442068 seconds time elapsed
>
> So cycles are off by roughly 2, instructions are off by roughly a factor
> of 2.5, branches by a factor of 2. Those 3 events are fairly close from
> one run to the next in the host.

Oh, there's the scaling issue that Peter pointed out.

Can you try the tests again, but now measuring just one counter per run 
(perf stat -e xxx command).


-- 
error compiling committee.c: too many arguments to function