Hi Andi, On Tue, Oct 30, 2007 at 09:21:02PM +0100, Andi Kleen wrote: > "Joerg Roedel" <[EMAIL PROTECTED]> writes: > > > I would like to answer what the special purpose of the get_cycles_sync() > > function is in the x86 architecture. In special I ask myself why > > this function has to be *sync*? > > Vojtech had one test that tested time monotonicity over CPUs > and it constantly failed until we added the CPUID on K8 C stepping. > He can give details on the test.
Interesting, I wasn't aware of that. > I suspect the reason was because the CPU reordered the RDTSCs so that > a later RDTSC could return a value before an earlier one. This can > happen because gettimeofday() is so fast that a tight loop calling it can > fit more than one iteration into the CPU's reordering window. Ok, that is the reason why the get_cycles_sync() function only exists on x86_64 and not on i386, because on i386 gettimeofday() is a real syscall? > That is why newer kernels use RDTSCP if available which doesn't need > to be intercepted and is synchronous. And since all AMD SVM systems > have RDTSCP they are fine. The problem with KVM here is that they wan't to migrate guests between Intel and AMD boxes. So they don't export RDTSCP or FEATURE_SYNC_TSC to the guests in the CPUID calls. A 64bit Linux guest will execute the CPUID in that function. Joerg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
