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 monotonicallyonPV

To: John Levon <levon@xxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Fix clock_gettime to increment monotonicallyonPV-domain/x86
From: Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>
Date: Fri, 15 Jun 2007 22:58:53 +0900
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>
Delivery-date: Fri, 15 Jun 2007 06:59:00 -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>
References: <20070615130808.GA13632@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi, John

Is there any plan to use vsyscall for clock_gettime on PV-dom?
I think this is the best solution for this.

But this kind of change is very large.

In this meaning, my patch is temporaly solution like within 4CPU.

Thanks
Atsushi SAKAI


John Levon <levon@xxxxxxxxxxxxxxxxx> wrote:

> 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



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