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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
