From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH kvm-unit-tests] pmu: fixes for Sandy Bridge hosts Date: Mon, 3 Jun 2013 10:38:50 +0300 Message-ID: <20130603073850.GX4725@redhat.com> References: <1369935788-19069-1-git-send-email-pbonzini@redhat.com> <20130602153209.GJ24773@redhat.com> <51AC38A9.5010703@redhat.com> <20130603063854.GU4725@redhat.com> <51AC40FE.5020005@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:65083 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818Ab3FCHiw (ORCPT ); Mon, 3 Jun 2013 03:38:52 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r537cq4b011160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 3 Jun 2013 03:38:52 -0400 Content-Disposition: inline In-Reply-To: <51AC40FE.5020005@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Jun 03, 2013 at 09:08:46AM +0200, Paolo Bonzini wrote: > Il 03/06/2013 08:38, Gleb Natapov ha scritto: > > On Mon, Jun 03, 2013 at 08:33:13AM +0200, Paolo Bonzini wrote: > >> Il 02/06/2013 17:32, Gleb Natapov ha scritto: > >>> On Thu, May 30, 2013 at 07:43:07PM +0200, Paolo Bonzini wrote: > >>>> This patch includes two fixes for SB: > >>>> > >>>> * the 3rd fixed counter ("ref cpu cycles") can sometimes report > >>>> less than the number of iterations > >>>> > >>> Is it documented? It is strange for "architectural" counter to behave > >>> differently on different architectures. > >> > >> It just counts the CPU cycles. If the CPU can optimize the loop better, > >> it will take less CPU cycles to execute it. > >> > > We should try and change the loop so that it will not be so easily optimized. > > Making the test succeed if only 10% percent of cycles were spend on a loop > > may result in the test missing the case when counter counts something > > different. > > Any hard-to-optimize loop risks becoming wrong on the other side (e.g. > if something stalls the pipeline, a newer chip with longer pipeline will > use more CPU cycles). > > Turbo boost could also contribute to lowering the number of cycles; a > boosted processor has ref cpu cycles that are _longer_ than the regular > cycles (thus they count in smaller numbers). Maybe that's why "core > cycles" didn't go below N. > "core cycles" are subject to Turbo boost changes, not ref cycles. Since instruction are executed at core frequency ref cpu cycles count may be indeed smaller. > The real result was something like 0.8*N (780-830000). I used 0.1*N > because it is used for the "ref cpu cycles" gp counter, which is not the > same but similar. Should I change it to 0.5*N or so? > For cpus with constant_tsc they should be the same. OK lets make gp and fixed use the same boundaries. -- Gleb.