From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: TSC scaling and softtsc reprise, and PROPOSAL Date: Tue, 04 Aug 2009 17:05:49 -0700 Message-ID: <4A78CCDD.9090205@goop.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Cc: Dan Magenheimer , "Xen-Devel (E-mail)" , "Dong, Eddie" , John Levon , Ian Pratt , "Zhang, Xiantao" List-Id: xen-devel@lists.xenproject.org On 07/24/09 01:04, Keir Fraser wrote: > Okay, so the issue you are worried about is not specific to Xen. So how is > native Linux tackling this, for example? > Linux will use the tsc where possible, but regularly assesses its perceived accuracy and will move to a different clocksource if the tsc appears to the playing up. I don't think it ever assumes the tsc is synced between CPU/cores. It allows rdtsc from usermode, but it is generally considered to be very buggy and ill-defined behaviour. It makes no attempt to make usermode rdtsc in any way meaningful. The exception is the vgettimeofday vsyscall which does Xen-like timekeeping, in which it gets the tsc,cpu tuple atomically, then scales it with timing parameters from the kernel. J