Messages in this thread | | | Date | Thu, 29 Oct 2009 07:46:05 -0700 (PDT) | From | Dan Magenheimer <> | Subject | RE: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation |
| |
> From: Avi Kivity [mailto:avi@redhat.com] > > On 10/28/2009 07:47 PM, Jeremy Fitzhardinge wrote: > >> Much better to have an API for this. Life is hacky enough already. > >> > > My point is that if an app cares about property X then it > should just > > measure property X. The fact that gettimeofday is a > vsyscall is just an > > implementation detail that apps don't really care about. > What they care > > about is whether gettimeofday is fast or not. > > > > But we can not make a reliable measurement. > > > If the environment has such unstable timing that the effect can't be > > measured, then it is moot whether its a vsyscall or not (but in that > > case its almost certainly better to use the standard API rather than > > trying to roll your own timesource with rdtsc). > > > > If you're interested in gettimeofday() for a global monotonic counter > you can fall back to atomic_fetch_and_add() which will be > faster than a > syscall even on large systems. Maybe we should provide a > vsyscall for > global monotonic counters and implement it using a atomics or tsc > instead of these hacks (I'm assuming here that the > gettimeofday() calls > are used to implement an atomic counter - are they?)
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.
| |