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 3/5] x86/pvclock: add vsyscall implementation

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation
From: Avi Kivity <avi@xxxxxxxxxx>
Date: Thu, 05 Nov 2009 08:47:01 +0200
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, kurt.hackel@xxxxxxxxxx, Glauber Costa <glommer@xxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, zach.brown@xxxxxxxxxx, Ingo Molnar <mingo@xxxxxxxxxx>, chris.mason@xxxxxxxxxx
Delivery-date: Wed, 04 Nov 2009 22:48:11 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <284e5d6c-7b31-4284-bd2d-c1d2ded1bc72@default>
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: <284e5d6c-7b31-4284-bd2d-c1d2ded1bc72@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4
On 11/04/2009 10:30 PM, Dan Magenheimer wrote:

In this case we should provide a facility for this.
Providing a global
monotonic counter may be easier than providing a monotonic
clock.  Hence
my question.
Maybe I'm misunderstanding something, but enterprise
apps can do this entirely on their own without any
kernel help, correct?

Within a process, yes. Across processes, not without writable shared memory.

That's why I'm trying to understand what the actual requirements are. Real monotonic, accurate, high resolution, low cost time sources are hard to come by.

I doubt it.  A discontinuity has occured, but what do we know
about it? nothing.
Actually, I think for many/most profiling applications,
just knowing a discontinuity occurred between two
timestamps is very useful as that one specific measurement
can be discarded.  If a discontinuity is invisible,
one clearly knows that a negative interval is bad,
but if an interval is very small or very large,
one never knows if it is due to a discontinuity or
due to some other reason.

This would argue for a syscall/vsyscall that can
"return" two values: the "time" and a second
"continuity generation" counter.

I doubt it. You should expect discontinuities in user space due to being swapped out, scheduled out, migrated to a different cpu, or your laptop lid being closed. There are no guarantees to a userspace application. Even the kernel can expect discontinuities due to SMIs. So an explicit notification about one type of discontinuity adds nothing.

True, though clock_gettime(CLOCK_MONOTONIC) can provide
the monotonicity where it is required.
We have that already.  The question is how to implement it in
a vsyscall.
Oh, I see.  I missed that very crucial point.

So, just to verify/clarify... There is NO WAY for
a vsyscall to ensure monotonicity (presumably because
the previous reading can't be safely stored?).  So
speed and "correctness" are mutually exclusive?


If true, yes, that's a potentially significant problem\
though an intelligent app can layer monotonicity
on top of the call I suppose.

Unless it's a multi-process app with limited trust.

Do not meddle in the internals of kernels, for they are subtle and quick to 

Xen-devel mailing list