Messages in this thread | | | Date | Wed, 31 Oct 2007 11:18:48 +0100 | From | Joerg Roedel <> | Subject | Re: Whats the purpose of get_cycles_sync() |
| |
Hi Andi,
On Tue, Oct 30, 2007 at 09:21:02PM +0100, Andi Kleen wrote: > "Joerg Roedel" <joerg.roedel@amd.com> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |