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: Thu, 16 Jun 2011 08:08:22 -0600 Message-ID: <4DFA0E56.70301@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> <4DF8E328.6070708@cisco.com> <4DFA0AC4.9050702@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]:50738 "EHLO sj-iport-6.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758152Ab1FPOIY (ORCPT ); Thu, 16 Jun 2011 10:08:24 -0400 In-Reply-To: <4DFA0AC4.9050702@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/16/2011 07:53 AM, Avi Kivity wrote: > 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 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. > > 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). > > Command: perf stat -e instructions openssl speed aes Guest: 135,522,189,056 instructions # 0.00 insns per cycle Host: 346,082,922,185 instructions # 0.00 insns per cycle Adding '--no-scale' to the perf-stat had no effect on the relative difference. David