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: "Nils Nieuwejaar" <nils.nieuwejaar@xxxxxxxxx>, "John Levon" <levon@xxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] RE: [PATCH] rendezvous-based local time calibration WOW!
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Sat, 9 Aug 2008 14:55:33 -0600
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Sat, 09 Aug 2008 13:56:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <9ab51d7e0808090747l4fde8e87ga368e7ae62f07de0@xxxxxxxxxxxxxx>
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>
Organization: Oracle Corporation
Reply-to: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acj6YkJY8vujdTQqR2K3LFiVOvBukg==
> On Wed, Aug 6, 2008 at 11:21 AM, John Levon 
> <levon@xxxxxxxxxxxxxxxxx> wrote:
> > On Wed, Aug 06, 2008 at 09:09:06AM -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.  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?


Xen-devel mailing list

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