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


[Xen-devel] RE: pvclock (PV and HVM) and vsyscall

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] RE: pvclock (PV and HVM) and vsyscall
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Sun, 17 Oct 2010 18:29:23 -0700 (PDT)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Tim Deegan <Tim.Deegan@xxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Sun, 17 Oct 2010 18:32:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CB8F1A9.4080909@xxxxxxxx>
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: <bea7d3ae-08a5-4298-8478-0af724010566@default 4CB8F1A9.4080909@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
> Sent: Friday, October 15, 2010 6:28 PM
> To: Dan Magenheimer
> Cc: Tim Deegan; Stefano Stabellini; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: pvclock (PV and HVM) and vsyscall
>  On 10/15/2010 08:48 AM, Dan Magenheimer wrote:
> > The other discussion of RADclock reminded me:
> >
> > IIRC the pvclock algorithm is still incompatible with
> > vsyscall/vdso (fast system calls) and there was no obvious
> > and upstreamable solution to resolve this.
> >
> > This means that any userland call to the various gettimeofday
> > routines will always do a true system call on both (a) a PV
> > domain or (b) any PV on HVM domain with Stefanos' pvclock patch.
> >
> > Since true syscalls are very expensive on a 64-bit
> > PV domain, I'm wondering if pvclock is still the right
> > default choice for upstream (at least for 64-bit).
> What other options are there?  If the tsc is globally stable, then
> using
> pvclock in userspace will work fine; if it isn't, you'll need to do the
> syscall anyway.
> There's no basic problem with the vsyscall pvclock patch so long as we
> can know under what circumstances it is safe to enable.

I think (but am not positive) that the circumstances under which
vsyscall pvclock can be enabled are exactly the same as those
for which tsc is globally stable.  And when tsc is globally stable,
upstream guest kernels can use tsc instead of pvclock.  And
when tsc is NOT globally stable, as of Xen 4.0, rdtsc emulation
is faster than non-vsyscall pvclock, at least in many/most

To quote the RADclock paper: "[the Xen Clocksource counter] works
well as intended, however note that it is a complex solution created
to solve a problem which will soon disappear as reliable TSC counters
again become ubiquitous."  (And, yes, we both know that there will
always be exceptions to "reliable" TSC, but that is in part why
rdtsc emulation is the default, and Xen and RADclock and pvclock
will all have the same problems as a native kernel when these exceptions

I'm afraid my available time is too limited right now to fight
this battle, but I think we should be very cautious about building
even more infrastructure on top of pvclock.

Xen-devel mailing list

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