From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] clocksource=tsc Date: Tue, 15 Jul 2008 16:08:35 +0100 Message-ID: References: <20080715084431031.00000080236@djm-pc> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20080715084431031.00000080236@djm-pc> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "dan.magenheimer@oracle.com" , "Xen-Devel (E-mail)" Cc: Dave Winchell List-Id: xen-devel@lists.xenproject.org On 15/7/08 15:44, "Dan Magenheimer" wrote: > 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. 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=tsc would be another possibility... > One other nit: Especially if the above is changed, do > you really prefer a strcmp vs a global variable (or > checking for size == 64) for determining if the tsc > is the platform timer? It's hidden in a macro and it's called very rarely. So I think it's fine. -- Keir