Re: [PATCH][2.5] notsc option needs some attention/TLC

["J.E.J. Bottomley" <James.Bottomley@HansenPartnership.com>]

> having this config option ass-backwards is mind-bogglingly confusing,
> and there seems no real reason for it. John had a plan to just put  in
> CONFIG_X86_PIT instead as the inverse of this, and delete
> CONFIG_X86_TSC. He seems to have gone off this idea for some reason I
> can't understand ... I think it solves a lot of these issues ...

Actually, this is partly my fault.  When the subarch code went in, the meaning 
of CONFIG_X86_TSC got altered to mean, 'If not y, don't use tsc at all' (so I 
could disable the TSC entirely for Voyager). Then, when code moved to 
kernel/timers we got some code with the old meaning and some with the new, 
hence the confusion.

The CONFIG_X86_PIT was something I added to try to clarify.  There are three 
cases with this:

PIT y, TSC n: Never use TSC, always use PIT
PIT y, TSC y: Try TSC at first, if it doesn't work, fall back to PIT
PIT n, TSC y: TSC always works, use it without testing.

Obviously PIT n, TSC n is bogus.

There are also two distinct usages of TSC:

1. do_fast_gettimeofday (now in timers) which *requires* the TSCs to be 
synchronised across all CPUs
2. more accurate udelay (which already has the mechanisms in place to cope 
with TSCs running at different rates).

1. is usually the reason why numa like machines want to disable the TSC 
entirely.

Linus isn't very happy with the global TSC disable patch (see 
http://marc.theaimsgroup.com/?t=103652952900006&r=1&w=2).  And wants a better 
solution.  (Then, of course, there are the additional timer options, like the 
cyclone).

James