From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756052AbYIDWJz (ORCPT ); Thu, 4 Sep 2008 18:09:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754264AbYIDWJq (ORCPT ); Thu, 4 Sep 2008 18:09:46 -0400 Received: from smtp-outbound-1.vmware.com ([65.113.40.141]:33848 "EHLO smtp-outbound-1.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752516AbYIDWJq (ORCPT ); Thu, 4 Sep 2008 18:09:46 -0400 Subject: Re: [RFC patch 0/4] TSC calibration improvements From: Alok Kataria Reply-To: akataria@vmware.com To: Linus Torvalds Cc: Alan Cox , Ingo Molnar , Thomas Gleixner , LKML , Arjan van de Veen , "H. Peter Anvin" , Peter Zijlstra In-Reply-To: References: <20080904150339.896115280@linutronix.de> <20080904153620.GC7120@elte.hu> <20080904160036.GA18382@elte.hu> <20080904190728.59634020@lxorguk.ukuu.org.uk> <1220564317.11753.70.camel@alok-dev1> Content-Type: text/plain Organization: VMware INC. Date: Thu, 04 Sep 2008 15:09:44 -0700 Message-Id: <1220566184.11753.87.camel@alok-dev1> Mime-Version: 1.0 X-Mailer: Evolution 2.8.0 (2.8.0-40.el5_1.1) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2008-09-04 at 14:52 -0700, Linus Torvalds wrote: > > On Thu, 4 Sep 2008, Alok Kataria wrote: > > > > The maximum count value that I see is 84. > > In one single reboot run, on an average in about 70 iterations the val > > returned from pit_expect_msb is > 50, and eventually we hit a condition > > where the value is < 50 and we bail out of the fast method. > > > > So just to be on safer side can we be a little less generous and > > increase the threshold to somewhere around 75 from 50 ? Or is there a > > good reason not to ? > > Why would you? > > The reason the single run completed successfully was apparently that no > actual virtualization event triggered, so it actually accessed the > hardware successfully and without any real slowdown. As shown also by the > fact that the actual frequency was correct at the end. > > The ones that failed presumably all had interrupts that happened in the > VM, which then immediately triggered the "uhhuh, there was a bump" thing. > > IOW, the code worked correctly as designed. It's not a > "anti-virtualization" feature per se, it's a "detect when virtualization > screws up timing". When virtualization (or SMI etc) does _not_ screw up > timing, it all works fine. Maybe i was just being too paranoid, the slow calibration method has been known to work correctly even under extreme stress conditions for us and wanted to make sure that we always take that path. Anyways I understand your point so lets stick with this value, if there are any false positives that I see with this i will get back. Thanks, Alok > > Linus