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/
Home Products Support Community News


Re: [Xen-devel] RE: [PATCH] rendezvous-based local time calibration WOW!

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] RE: [PATCH] rendezvous-based local time calibration WOW!
From: John Levon <levon@xxxxxxxxxxxxxxxxx>
Date: Wed, 6 Aug 2008 14:38:29 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Wed, 06 Aug 2008 06:39:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080806072550375.00000008444@djm-pc>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20080805211251.GA27007@xxxxxxxxxxxxxxxxxxxxxxx> <20080806072550375.00000008444@djm-pc>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Wed, Aug 06, 2008 at 07:25:50AM -0600, Dan Magenheimer wrote:

> > > I'm not sure its possible to guarantee monotonicity in
> > > PV domains (without a global lock) except by doing a trap
> > > or hypercall at each "get time".
> > 
> > That's a shame.
> Further followup on this...
> I'd encourage you to put some test code in your lock to
> see if time ever measurably goes backwards.  It may never,
> or it may only on some ill-behaved-tsc machines or when
> cpufreq changes occur... needs testing.  Even if it
> does, it may be by a smaller delta than all but the
> most sophisticated SMP applications can detect.

I believe the normal (metal) Solaris algorithm expects any inter-CPU TSC
differences to remain static (that is, no drift), so any machine that
breaks that is problematic:




The presumption is that gethrtimef() is monotonically increasing, which
at least Xen 3.0.4 regularly broke. If the hypervisor has been fixed to
give as much guarantees as we got already then great.

A monotonic gethrtime() is part of the ABI so I'm not sure we can avoid
a lock even on well-behaved machines if Xen isn't correct.

I wonder if we couldn't do something when we know that we're scheduling
a VPCU onto a different CPU to ensure time can't go backwards.

Anyway, some more testing sounds like it would be interesting.


Xen-devel mailing list

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