| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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: |
Tue, 03 Nov 2009 07:12:02 +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: |
Mon, 02 Nov 2009 21:13:01 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<78f9bb94-fb5d-4fe7-b20f-774bb14e360f@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: |
<78f9bb94-fb5d-4fe7-b20f-774bb14e360f@default> |
|
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-3.9.b4.fc12 Thunderbird/3.0b4 |
On 11/02/2009 05:46 PM, Dan Magenheimer wrote:
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.
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.
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 doubt it. A discontinuity has occured, but what do we know about it?
nothing.
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.
We have that already. The question is how to implement it in a vsyscall.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home