Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1424237AbWKJLUL (ORCPT ); Fri, 10 Nov 2006 06:20:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1424384AbWKJLUL (ORCPT ); Fri, 10 Nov 2006 06:20:11 -0500 Received: from mx2.mail.elte.hu ([157.181.151.9]:33956 "EHLO mx2.mail.elte.hu") by vger.kernel.org with ESMTP id S1424237AbWKJLUJ (ORCPT ); Fri, 10 Nov 2006 06:20:09 -0500 Date: Fri, 10 Nov 2006 12:19:02 +0100 From: Ingo Molnar To: Alan Cox Cc: Andrew Morton , tglx@linutronix.de, Andi Kleen , john stultz , LKML , Len Brown , Arjan van de Ven , Roman Zippel Subject: Re: [patch 13/19] GTOD: Mark TSC unusable for highres timers Message-ID: <20061110111902.GC4780@elte.hu> References: <20061109233030.915859000@cruncher.tec.linutronix.de> <20061109233035.569684000@cruncher.tec.linutronix.de> <1163121045.836.69.camel@localhost> <200611100610.13957.ak@suse.de> <1163146206.8335.183.camel@localhost.localdomain> <20061110005020.4538e095.akpm@osdl.org> <20061110085728.GA14620@elte.hu> <1163153670.7900.16.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1163153670.7900.16.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.2i X-ELTE-SpamScore: -2.8 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.8 required=5.9 tests=ALL_TRUSTED,AWL,BAYES_50 autolearn=no SpamAssassin version=3.0.3 -3.3 ALL_TRUSTED Did not pass through any untrusted hosts 0.5 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5000] -0.0 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1549 Lines: 38 * Alan Cox 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/