Re: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation
From: john stultz
Date: Wed Nov 04 2009 - 16:19:45 EST
On Thu, Oct 29, 2009 at 7:07 AM, Avi Kivity <avi@xxxxxxxxxx> wrote:
> On 10/29/2009 04:46 PM, Dan Magenheimer wrote:
>> No, the apps I'm familiar with (a DB and a JVM) need a timestamp
>> not a monotonic counter. The timestamps must be relatively
>> accurate (e.g. we've been talking about gettimeofday generically,
>> but these apps would use clock_gettime for nsec resolution),
>> monotonically increasing, and work properly across a VM
>> migration. The timestamps are taken up to a 100K/sec or
>> more so the apps need to ensure they are using the fastest
>> mechanism available that meets those requirements.
> Out of interest, do you know (and can you relate) why those apps need
> 100k/sec monotonically increasing timestamps?
This is sort of tangential, but depending on the need, this might be
of interest: Recently I've added a new clock_id,
CLOCK_MONOTONIC_COARSE (as well as CLOCK_REALTIME_COARSE), which
return a HZ granular timestamp (same granularity as filesystem
timestamps). Its very fast to access, since there's no hardware to
touch, and is accessible via vsyscall.
The idea being, if your hitting clock_gettime 100k/sec but you really
don't have the need for nsec granular timestamps, it might provide a
really nice performance boost.
Here's the commit:
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/