WARNING - OLD ARCHIVES

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

xen-devel

Re: [Xen-devel] [PATCH 05/12] xen/pvclock: add monotonicity check

To: john stultz <johnstul@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 05/12] xen/pvclock: add monotonicity check
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 15 Oct 2009 20:10:56 -0700
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, kurt.hackel@xxxxxxxxxx, arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Avi Kivity <avi@xxxxxxxxxx>, chris.mason@xxxxxxxxxx
Delivery-date: Thu, 15 Oct 2009 20:11:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1f1b08da0910151832m59d14ac2i4add6555d6a1208a@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>
References: <4AD6B1F0.6030904@xxxxxxxx> <c7f37ead-3cf2-4277-a44e-425a7b940d31@default> <1f1b08da0910151832m59d14ac2i4add6555d6a1208a@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-2.7.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4
On 10/15/09 18:32, john stultz wrote:
>>> No, cycle_last isn't updated on every read, only on timer ticks.  This
>>> test doesn't seem to be intended to make sure that every
>>> clocksource_read is globally monotonic, but just to avoid
>>> some boundary
>>> conditions in the timer interrupt.  I just copied it directly from
>>> read_tsc().
>>>       
>> I understand but you are now essentially emulating a
>> reliable platform timer with a potentially unreliable
>> (but still high resolution) per-CPU timer AND probably
>> delivering that result to userland.
>>
>> Read_tsc should only be used if either CONSTANT_TSC
>> or TSC_RELIABLE is true, so read_tsc is guaranteed
>> to be monotonically-strictly-increasing by hardware
>> (and enforced for CONSTANT_TSC by check_tsc_warp
>> at boot).
>>     
> Ideally, yes, only perfect TSCs should be used.
>
> But in reality, its a big performance win for folks who can get away
> with just slightly offset TSCs.
>   

What monotonicity guarantees do we make to usermode, for both syscall
and vsyscall gettimeofday and clock_gettime?

Though its not clear to me how usermode would even notice very small
amounts of cross-thread/cpu non-monotonicity anyway.  It would need make
sure that it samples the time and stores it to some globally visible
place atomically (with locks, compare-and-swap, etc), which is going to
be pretty expensive.  And if its going to all that effort it may as well
do its own monotonicity checking/adjustments if its all that important.

(I can think of plenty of ways of doing it incorrectly, where you'd get
apparent non-monotonicity regardless of the quality of the time source.)

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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