From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: [PATCH v2 00/11] KVM in-guest performance monitoring Date: Wed, 15 Jun 2011 10:51:52 -0600 Message-ID: <4DF8E328.6070708@cisco.com> References: <1307972106-2468-1-git-send-email-avi@redhat.com> <4DF66B1A.6060606@cisco.com> <4DF71DA3.2080300@redhat.com> <4DF7972F.3040103@cisco.com> <4DF79941.9050705@siemens.com> <4DF79B6F.10102@cisco.com> <4DF79EFE.1050201@cisco.com> <4DF7A436.8090308@cisco.com> <4DF873FD.6040903@redhat.com> <4DF8A82F.5090900@cisco.com> <4DF8B1F8.6030502@redhat.com> <4DF8D8FE.2080808@cisco.com> <4DF8DD87.8040905@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Arnaldo Carvalho de Melo To: Avi Kivity Return-path: Received: from sj-iport-6.cisco.com ([171.71.176.117]:11518 "EHLO sj-iport-6.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751189Ab1FOQvx (ORCPT ); Wed, 15 Jun 2011 12:51:53 -0400 In-Reply-To: <4DF8DD87.8040905@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 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 ( 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.