Messages in this thread | | | From | Andrew Lutomirski <> | Date | Mon, 18 Apr 2011 16:39:21 -0400 | Subject | Re: [RFT] Please test rdtsc on various x86-64 hardware (app included) |
| |
On Mon, Apr 18, 2011 at 4:35 PM, Colin Walters <walters@verbum.org> wrote: > On Mon, Apr 18, 2011 at 4:27 PM, Andrew Lutomirski <luto@mit.edu> wrote: > >> Well, crap. Can you run: >> dmesg | grep -i tsc > > # dmesg|grep -i tsc > [ 0.000000] Fast TSC calibration using PIT > [ 0.098999] TSC synchronization [CPU#0 -> CPU#1]: > [ 0.098999] Measured 2399269672 cycles TSC warp between CPUs, > turning off TSC clock. > [ 0.098999] Marking TSC unstable due to check_tsc_sync_source failed > >> There are two possible explanations: >> 1. Your tscs are out of sync, and whether the test notices or not >> depends on which cpus the scheduler sticks the threads on. > > Looks like that's the case? But for what you want to do in kernel, > the kernel already did this test and so would know to not use the TSC > for vgettimeofday(), right? (I only sort of followed the clock > discussion earlier but I found it quite interesting, so decided to run > the test). >
Yes, the kernel won't run this code at all on your system. That being said, you have the constant_tsc flag and the error my tool measured is pretty close to the error the kernel measured at boot, so it might be interesting for the kernel to learn how to synchronize the TSCs itself. This is possible, abeit awkward, on newish Intel CPUs. It's possible but *really* awkward on older CPUs.
--Andy -- 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/
| |