|| ||Ingo Molnar <mingo-AT-elte.hu>|
|| ||Alan Cox <alan-AT-lxorguk.ukuu.org.uk>|
|| ||Re: [patch 13/19] GTOD: Mark TSC unusable for highres timers|
|| ||Fri, 10 Nov 2006 12:19:02 +0100|
|| ||Andrew Morton <akpm-AT-osdl.org>, tglx-AT-linutronix.de,
Andi Kleen <ak-AT-suse.de>, john stultz <johnstul-AT-us.ibm.com>,
LKML <linux-kernel-AT-vger.kernel.org>, Len Brown <lenb-AT-kernel.org>,
Arjan van de Ven <arjan-AT-infradead.org>,
Roman Zippel <zippel-AT-linux-m68k.org>|
* Alan Cox <firstname.lastname@example.org> wrote:
> Ar Gwe, 2006-11-10 am 09:57 +0100, ysgrifennodd Ingo Molnar:
> > AFAIK Windows doesnt use it, so it's a continuous minefield for new
> > hardware to break.
> Windows uses it extensively especially games. The AMD desync upset a
> lot of Windows gamers.
well, i meant the Windows kernel itself, not applications. (maybe the
Windows kernel uses it on SMP systems where the TSC /used to be/ pretty
stable, i dont know)
> > We should wait until CPU makers get their act together and implement
> > a TSC variant that is /architecturally promised/ to have constant
> > frequency (system bus frequency or whatever) and which never stops.
> This will never happen for the really big boxes, light is just too
> slow... [...]
that's not a problem - time goes as fast as light [by definition] :-)
> If hrtimer needs and requires we stop TSC support [...]
no, it doesnt, so there's no real friction here. We just observed that
in the past 10 years no generally working TSC-based gettimeofday was
written (and i wrote the first version of it for the Pentium, so the
blame is on me too), and that we might be better off without it. If
someone can pull off a working TSC-based gettimeofday() implementation
then there's no objection from us.
to post comments)