From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] Fix clock_gettime to increment monotonically onPV-domain/x86 Date: Fri, 15 Jun 2007 14:21:12 +0100 Message-ID: References: <20070615130808.GA13632@totally.trollied.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070615130808.GA13632@totally.trollied.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: John Levon , Keir Fraser Cc: Atsushi SAKAI , xen-devel@lists.xensource.com, Jan Beulich List-Id: xen-devel@lists.xenproject.org On 15/6/07 14:08, "John Levon" wrote: >>> This is essentially what we've got now in Solaris. It seems like a >>> terrible shame not to just fix it in Xen, especially given all that >>> traffic from all CPUs to 'last_ret'. >> >> How would we fix it in Xen in a way that is faster and more scalable? > > A good question :) > > One thing we've considered is losing some precision based upon how much > of a delta there is between the real CPUs (i.e. drop lower bits and > round up). But we're still (slowly) looking into the problem. IIUC this would make it less likely to see time going backwards, but when you do it'll be by a lot more (the size of your precision granularity), and it'll occur when your time values are unlucky enough to be just on the wrong sides of a boundary between two time intervals which map to different lower-precision time values. I believe it's a pretty fundamental property of a monotonically-increasing counter in a distributed system that communication is required to implement it. Time is a funny thing. -- Keir