From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: [PATCH] clocksource=tsc Date: Tue, 15 Jul 2008 09:46:09 -0600 Message-ID: <20080715094609687.00000080236@djm-pc> References: Reply-To: "dan.magenheimer@oracle.com" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , "Xen-Devel (E-mail)" Cc: Dave Winchell List-Id: xen-devel@lists.xenproject.org > > Hmmm... One thing I was trying to do with the special > > casing in get_s_time() was to avoid using a dynamically > > changing scaling (t->tsc_scale). If I'm not mistaken, > > t->tsc_scale is recalculated every EPOCH and thus is > > a potential source of stime jitter. Seems unnecessary > > just to make the code look cleaner. > = > My patch disables the per-epoch calibration. OK, then I think it is the calls to calibrate_tsc_ap() that result in different values of tsc_scale (potentially a different one for every processor depending on the precision of the calibration). I still think it would be clearer and safer to always use a fixed tsc_scale value. > Actually in this mode of operation we hardly need a platform = > timer *at all*. > The idea is that we let the TSCs free-run, because we know = > they will behave. > Returning to 32-bit read_counter(), and having NULL read_counter when > clocksource=3Dtsc would be another possibility... That's essentially what the original tscstable.patch did, though I was perhaps much uglier in the miscellaneous parts. Thanks, Dan