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

[David Ahern <daahern@cisco.com>]

On 06/15/2011 10:27 AM, Avi Kivity wrote:
> On 06/15/2011 07:08 PM, David Ahern wrote:
>> >  What does
>> >  dmesg say about Perf?
>>
>> [    0.050995] Performance Events: Nehalem events, core PMU driver.
>> [    0.051466] ... version:                1
>> [    0.052998] ... bit width:              40
>> [    0.053999] ... generic registers:      2
>> [    0.054998] ... value mask:             000000ffffffffff
>> [    0.055998] ... max period:             000000007fffffff
>> [    0.057997] ... fixed-purpose events:   0
>> [    0.058998] ... event mask:             0000000000000003
> 
> Well, it's not a Nehalem.  Can you tweak the model/family (via -cpu
> host) so it doesn't match a Nehalem and instead falls on the
> architectural PMU?
> 
> Trial-and-error should work to find a good combo.

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.