lkml.org 
[lkml]   [2011]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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/

\
 
 \ /
  Last update: 2011-04-18 22:41    [W:0.045 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site