From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC PATCH 0/3] generic hypercall support Date: Sat, 09 May 2009 11:45:10 +0300 Message-ID: <4A054296.4070604@redhat.com> References: <4A010927.6020207@novell.com> <20090506072212.GV3036@sequoia.sous-sol.org> <4A018DF2.6010301@novell.com> <20090506160712.GW3036@sequoia.sous-sol.org> <4A031471.7000406@novell.com> <20090507233503.GA9103@amt.cnet> <20090507234311.GA9517@amt.cnet> <4A03E579.8030201@redhat.com> <20090508143507.GA8319@amt.cnet> <4A0445A0.4060104@novell.com> <20090508155109.GA9269@amt.cnet> <4A048E78.6020605@cisco.com> <4A048F93.1050601@novell.com> <4A04BEE5.2080600@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gregory Haskins , Marcelo Tosatti , Chris Wright , Gregory Haskins , kvm@vger.kernel.org, Anthony Liguori To: "David S. Ahern" Return-path: Received: from mx2.redhat.com ([66.187.237.31]:46321 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751541AbZEIIqK (ORCPT ); Sat, 9 May 2009 04:46:10 -0400 In-Reply-To: <4A04BEE5.2080600@cisco.com> Sender: kvm-owner@vger.kernel.org List-ID: David S. Ahern wrote: > I ran another test case with SMT disabled, and while I was at it > converted TSC delta to operations/sec. The results without SMT are > confusing -- to me anyways. I'm hoping someone can explain it. > Basically, using a count of 10,000,000 (per your web page) with SMT > disabled the guest detected a soft lockup on the CPU. So, I dropped the > count down to 1,000,000. So, for 1e6 iterations: > > without SMT, with EPT: > HC: 259,455 ops/sec > PIO: 226,937 ops/sec > MMIO: 113,180 ops/sec > > without SMT, without EPT: > HC: 274,825 ops/sec > PIO: 247,910 ops/sec > MMIO: 111,535 ops/sec > > Converting the prior TSC deltas: > > with SMT, with EPT: > HC: 994,655 ops/sec > PIO: 875,116 ops/sec > MMIO: 439,738 ops/sec > > with SMT, without EPT: > HC: 994,304 ops/sec > PIO: 903,057 ops/sec > MMIO: 423,244 ops/sec > > Running the tests repeatedly I did notice a fair variability (as much as > -10% down from these numbers). > > Also, just to make sure I converted the delta to ops/sec, the formula I > used was cpu_freq / dTSC * count = operations/sec > > The only think I can think of is cpu frequency scaling lying about the cpu frequency. Really the test needs to use time and not the time stamp counter. Are the results expressed in cycles/op more reasonable? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.