From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: [RFC] [PATCH] use "reliable" tsc properly when available, but verify Date: Tue, 29 Sep 2009 11:10:15 -0700 (PDT) Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 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)" List-Id: xen-devel@lists.xenproject.org > > Does that make more sense? >=20 > That makes it a nice-to-have. But not nice enough to have all=20 > CPUs groove > off for 2ms every once in a while, imo. OK, rechecking may be too paranoid. I will rewrite to run once at boottime and resubmit. (Is 20ms at boottime OK? 20ms matches Linux.) > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: Monday, September 21, 2009 12:17 PM > > Well, if it is at least true for 99% of systems, then it=20 > might be worth > enabling constant_tsc support by default, and detect TSC divergence at > runtime and disbale dynamically. I think that's what Linux=20 > does (i.e., it > has a fallback at runtime if its TSC assumptions turn out to=20 > be wrong). Looking more closely at the upstream Linux code though, any processor deemed to have X86_FEATURE_TSC_RELIABLE NEVER runs check_tsc_warp and never validates TSC (except in the unusual circumstance that the kernel was compiled with NUMAQ enabled). If this feature is set, Linux just uses tsc as the best clocksource and afaict has no fallback. I'd feel better running check_tsc_warp (at least) once on ALL processors, even if X86_FEATURE_TSC_RELIABLE is set. Is that OK? Or should we just trust it under exactly the same circumstances as Linux does? Thanks, Dan