Re: [patch 13/19] GTOD: Mark TSC unusable for highres timers

[Ingo Molnar]

* Pavel Machek <pavel@xxxxxx> wrote:

> > > If so, could that function use the PIT/pmtimer/etc for working out 
> > > if the TSC is bust, rather than directly using jiffies?
> > 
> > there's no realiable way to figure out the TSC is bust: some CPUs 
> > have a slight 'skew' between cores for example. On some systems the 
> > TSC might skew between sockets. A CPU might break its TSC only once 
> > some
> 
> But we could still do a whitelist?

we could, but it would have to be almost empty right now :-) Reason: 
even on systems that have (hardware-initialized) 'perfect' TSCs and 
which do not support any frequency scaling or power-saving mode, our 
current TSC initialization on SMP systems introduces a small (1-2 usecs) 
skew.

but even that limited set of systems is now mostly obsolete: no 
multi-core CPU based system i'm aware of would qualify. I have written 
user-space testcode for TSC and gettimeofday warps, see:

   http://redhat.com/~mingo/time-warp-test/time-warp-test.c

no SMP system i have passes at the moment, running 2.6.17/18:

 --------------------------------------
 jupiter:~> ./time-warp-test
 4 CPUs, running 4 parallel test-tasks.
 checking for time-warps via:
 - read time stamp counter (RDTSC) instruction (cycle resolution)
 - gettimeofday (TOD) syscall (usec resolution)

 [...]
 new TSC-warp maximum:     -6392 cycles, 0000294e1f3b6100 -> 0000294e1f3b4808
 | # of TSC-warps:183606 |

 --------------------------------------
 venus:~> ./time-warp-test
 4 CPUs, running 4 parallel test-tasks.
 [...]
 new TSC-warp maximum:     -1328 cycles, 00001d9549c6c738 -> 00001d9549c6c208
 | # of TSC-warps:332510 |

 --------------------------------------
 neptune:~> ./time-warp-test
 2 CPUs, running 2 parallel test-tasks.
 [...]
 new TSC-warp maximum:      -332 cycles, 0000005e00b1b89e -> 0000005e00b1b752
 | # of TSC-warps:340 |

 [and i'm lazy to turn on the 8-way now, but that has TSC warps too.]

so i'd love to see non-warping time, but after 10 years of trying i'm 
not holding my breath.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/