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: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 05/12] xen/pvclock: add monotonicity check
From: john stultz <johnstul@xxxxxxxxxx>
Date: Thu, 15 Oct 2009 18:32:26 -0700
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, 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: Fri, 16 Oct 2009 05:29:14 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=iw5a5cqNM9lqhSuOmMl8wesi6OIw6Z+m8GqTq6uoiKM=; b=kw99qnMdZcRNPmD8XMy+AzsIuU+X1EUSpfyxblcELXU5nKRDShgcay1EqKOwlVaQSP YmR7W0aLiER/jVx8SrkMopPKiGUsIlT2bqaWeQTJsAka2Hs98iO6mFN6GkQV8TD4kuF+ QuN8jyFSb+kbU/r78MVqQ2DO6kRFGtLE9U+Pg=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=P/5v6cXVaCxqlKvhjlvVrHtofDuTfC1i8jJ8dSSP9DuXJkXYgbCr/Xw51NKL5n6Evi 6hvqs67xFsfICmUxdj0HoXs9N+49IO4o6y1/Rqp4nsiKOT+Jzc5Vqk0+UVbhAXjoqpaJ fgVLvYiZmZOWTrW/ECq7Mv7LLEb6wQbts2gs8=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <c7f37ead-3cf2-4277-a44e-425a7b940d31@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: <4AD6B1F0.6030904@xxxxxxxx> <c7f37ead-3cf2-4277-a44e-425a7b940d31@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, Oct 15, 2009 at 6:27 AM, Dan Magenheimer
<dan.magenheimer@xxxxxxxxxx> wrote:
>> On 10/14/09 20:26, Dan Magenheimer wrote:
>> > As long as we are going through the trouble of making
>> > this monotonic, shouldn't it be monotonically increasing
>> > (rather than just monotonically non-decreasing)?  The
>> > rdtsc instruction and any suitably high-precision
>> > hardware timer will never return the same value
>> > on subsequent uses so this might be a reasonable
>> > precedent to obey.  E.g.
>> >
>> > +   return ret > xen_clocksource.cycle_last ?
>> > +           ret : ++xen_clocksource.cycle_last;

Oof. Modifying .cycle_last will cause timekeeping wreckage.  Please don't.
Also the above would break on SMP.

Ideally we would have moved cycle_last to the timekeeper structure,
since its a timekeeping specific value, not really clocksource
related.

However, there is the situation where we have don't have perfectly
synced TSCs, but TSCs that are very very close. In this case, the only
time we might see skew is if update_wall time were to run on the
slightly faster TSC, and then immediately after the gettimeofday()
code runs and sees the cycle_last value ahead of the rdtsc.

So the cycle_last check is hackish, but it lets folks use the much
faster TSC when we'd have to otherwise throw it out.

If you wanted something like this, a global last_tsc value could be
used and cmpxchged to ensure you always have an increasing TSC value.
However I suspect the performance hit there would be painful.

>> 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.

thanks
-john

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

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