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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 Nov 2006 12:48:06 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Pavel Machek <pavel@....cz>
Cc:	Andrew Morton <akpm@...l.org>, tglx@...utronix.de,
	Andi Kleen <ak@...e.de>, john stultz <johnstul@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>, Len Brown <lenb@...nel.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Roman Zippel <zippel@...ux-m68k.org>
Subject: Re: [patch 13/19] GTOD: Mark TSC unusable for highres timers


* Pavel Machek <pavel@....cz> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/