| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation
|
To: |
Avi Kivity <avi@xxxxxxxxxx> |
|
Subject: |
RE: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation |
|
From: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
|
Date: |
Mon, 2 Nov 2009 07:46:06 -0800 (PST) |
|
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: |
Mon, 02 Nov 2009 07:47:33 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4AED55C9.9010301@xxxxxxxxxx> |
|
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 |
> > I don't have any public data available for this DB usage,
>
> Sorry, that doesn't explain anything.
Well for now just consider the DB usage as another use
of profiling. But one can easily draw scenarios where
a monotonic timestamp is also used to guarantee transaction
ordering.
> > Search for "flight recorder". This feature is intended to
> > be enabled all the time, but with non-vsyscall gettimeofday
> > the performance impact is unacceptably high, so they are using
>
> For profiling work fast timestamping is of course great, but surely
> there is no monotonicity requirement?
Yes and no. Monotonicity is a poor substitute for a more
generic mechanism that might provide an indication that a
discontinuity has occurred (forward or backward); if an app
could get both the timestamp AND some kind of "continuity
generation counter" (basically a much more sophisticated
form of TSC_AUX that changes whenever the timestamp is
coming from a different source), perhaps all problems could be solved.
> I don't think we'll be able to provide monotonicity with vsyscall on
> tsc-broken hosts, so we'll be limited to correcting the tsc frequency
> after migration for good-tsc hosts.
True, though clock_gettime(CLOCK_MONOTONIC) can provide
the monotonicity where it is required.
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home