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

[Andi Kleen]

> But that's different.
> 
> We're limping along in a semi-OK fashion with the TSC.  But now Thomas is
> proposing that we effectively kill it off for all x86 because of hrtimers.

I'm totally against that.
 
> And afaict the reason for that is that we're using jiffies to determine if
> the TSC has gone bad, and that test is getting false positives.


The i386 clocksource had always trouble with that. e.g.  I have a box
where the TSC works perfectly fine on a 64bit kernel, but since the new i386
clocksource code is in it always insists on disabling it shortly after boot.
My guess is that some of the checks in there are just broken and need
to be fixed.



> 
> > 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.
> > 
> 
> That'll hurt the big machines rather a lot, won't it?

It's unrealistic and short term it will cause extreme pain in many workloads
which are gettimeofday intensive (networking, databases etc.) 

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/