[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061110111902.GC4780@elte.hu>
Date: Fri, 10 Nov 2006 12:19:02 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
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
* Alan Cox <alan@...rguk.ukuu.org.uk> 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.
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/
Powered by blists - more mailing lists