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: Mon, 11 Aug 2008 15:37:13 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, Nils Nieuwejaar <nils.nieuwejaar@xxxxxxxxx>, Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 11 Aug 2008 07:38:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080809145533500.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: <9ab51d7e0808090747l4fde8e87ga368e7ae62f07de0@xxxxxxxxxxxxxx> <20080809145533500.00000008444@djm-pc>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Sat, Aug 09, 2008 at 02:55:33PM -0600, Dan Magenheimer wrote:

> > >> Again no guarantees but I think we are now under the magic
> > >> threshold where the skew is smaller than the time required
> > >> for scheduling a VCPU onto a different CPU.  If so,
> > >> consecutive gethrtime's by the same thread in a domain
> > >> should always be monotonic.
> > >
> > > Right! That sounds positive.
> > 
> > It's an improvement, but I'm pretty sure it's still not sufficient for
> > Solaris.  If I understand the change correctly, it seems to solve the
> > problem for single-vcpu guests on an SMP,  but not for multi-vcpu
> > guests on an SMP.  It sounds like the OS could reschedule a thread
> > from VCPU 0 to VCPU 1 and consecutive calls to gethrtime() could still
> > return non-monotonic results.
> How long does it take for Solaris to reschedule a thread from
> VCPU0 to VCPU1?  Its certainly not zero time (and you also need
> to add the overhead of gethrtime).
> But, yes, the same "no guarantees" applies to this situation...
> if a Solaris thread continuously calls gethrtime(), there is a
> non-zero probability that, if the thread changes physical CPUs
> and the thread rescheduling code is "very fast",
> two consecutive calls could observe time going backwards.

It's only non-zero if we can indeed reschedule fast enough. If it's now
below the threshold, then we can consider it effectively fixed. Only
testing can really tell us that.

>  But that's true with much recent vintage hardware because TSCs
>  sometimes skew, and so most OS's with high-res timers are able to
>  deal with this.
> True of Solaris, John?

I'm not an expert on the relevant code, but I believe the solution to
TSC drift (as Solaris calls what I think you call skew) is to set
'tsc_gethrtime_enable' to zero, so we don't use the TSC for this


Xen-devel mailing list

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