| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH 05/12] xen/pvclock: add monotonicity check
|
To: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
|
Subject: |
RE: [Xen-devel] [PATCH 05/12] xen/pvclock: add monotonicity check |
|
From: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
|
Date: |
Thu, 15 Oct 2009 06:27:24 -0700 (PDT) |
|
Cc: |
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 06:35:35 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4AD6B1F0.6030904@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> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
> 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;
>
> 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).
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home