* Pavel Machek <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
