Messages in this thread | | | Date | Thu, 5 Nov 2009 06:52:38 -0800 (PST) | From | Dan Magenheimer <> | Subject | RE: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation |
| |
> From: Avi Kivity [mailto:avi@redhat.com] > > Within a process, yes. Across processes, not without writable shared > memory. > > That's why I'm trying to understand what the actual > requirements are. > Real monotonic, accurate, high resolution, low cost time sources are > hard to come by.
Hmmm... this has significant implications for the rdtsc emulation discussion on xen-devel. Since that's not a Linux question, I'll start another thread on xen-devel with a shorter cc list.
> > Actually, I think for many/most profiling applications, > > just knowing a discontinuity occurred between two > > timestamps is very useful as that one specific measurement > > can be discarded. If a discontinuity is invisible, > > one clearly knows that a negative interval is bad, > > but if an interval is very small or very large, > > one never knows if it is due to a discontinuity or > > due to some other reason. > > > > This would argue for a syscall/vsyscall that can > > "return" two values: the "time" and a second > > "continuity generation" counter. > > I doubt it. You should expect discontinuities in user space due to > being swapped out, scheduled out, migrated to a different > cpu, or your > laptop lid being closed. There are no guarantees to a userspace > application. Even the kernel can expect discontinuities due > to SMIs. > So an explicit notification about one type of discontinuity > adds nothing.
Good point. I'm interested in enterprise apps that have more control over the machine (and rarely suffer from laptop lid closures :-) and would intend for all discontinuities visible to a hypervisor or kernel to increment "AUX", but bare-metal- kernel-invisible discontinuities such as SMI do throw a wrench in the works.
Well, all this discussion has convince me that my original proposals do make sense for enterprise apps to be virtualization-aware and use rdtsc/p directly for timestamping needs rather than OS APIs (with the hypervisor deciding whether or not to emulate rdtsc/p based on the underlying physical machine and whether or not migration is enabled or has occurred).
| |