WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Fix clock_gettime to increment monotonically onP

To: John Levon <levon@xxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Fix clock_gettime to increment monotonically onPV-domain/x86
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Fri, 15 Jun 2007 14:21:12 +0100
Cc: Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Jan Beulich <jbeulich@xxxxxxxxxx>
Delivery-date: Fri, 15 Jun 2007 06:17:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070615130808.GA13632@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcevUAr9SWs6NBtDEdyfcQAWy6hiGQ==
Thread-topic: [Xen-devel] [PATCH] Fix clock_gettime to increment monotonically onPV-domain/x86
User-agent: Microsoft-Entourage/11.3.3.061214
On 15/6/07 14:08, "John Levon" <levon@xxxxxxxxxxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>