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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Fix clock_gettime to increment monotonically onPV-domain/x86
From: John Levon <levon@xxxxxxxxxxxxxxxxx>
Date: Fri, 15 Jun 2007 14:08:08 +0100
Cc: Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>
Delivery-date: Fri, 15 Jun 2007 06:06:06 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2984BC8.9373%Keir.Fraser@xxxxxxxxxxxx>
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>
References: <20070615124713.GA12478@xxxxxxxxxxxxxxxxxxxxxxx> <C2984BC8.9373%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Fri, Jun 15, 2007 at 01:59:36PM +0100, Keir Fraser wrote:

> >> An alternative to a spin lock would be to use a 64-bit variable storing the
> >> raw
> >> nanosecond value, and use cmpxchg to check/update it. I did it this way for
> >> the clocksource monotonicity:
> > 
> > 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.

regards
john

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

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