Re: [patch] prefer TSC over PM Timer

[Dominik Brodowski <linux@dominikbrodowski.de>]

On Tue, Nov 16, 2004 at 01:50:44AM -0800, john stultz wrote:
> > 
> > right -- except i think the default is the opposite of what it should be 
> > for a generic kernel.  i think more systems are served better by using tsc 
> > than those that need clock=pm...  NUMA systems are rare (with custom 
> > kernels/etc), and if my experience with the centrino is valid then newer 
> > laptops aren't having this tsc/cpufreq problem.

Oh yes, they do -- as Venkatesh pointed out, the TSC stops if the CPU is in
the "deep sleep" power state. And better support for deeper sleep states is
in the working...

Also, the cpufreq code currently can only update the timing code with an
inaccuracy of up to one jiffy. If transitions happen in between two timer
ticks, timing becomes inaccurate by -0.5<x<0.5 jiffy. So, if you're
transitioning back and forth a lot, it becomes quite inaccurate over time.
It's the best we can do, and with john's new timer core, we'll be able to
reduce this issue to zero.

In addition, notebooks won't be changing their CPU's frequency behind their 
kernel's back in future as often -- a call to disable this BIOS interference
was added into 2.6.10-rc2.

> Yea, no, I definitely don't like that. I know how these tricks work,
> send out a worse patch to make the first look better ;) But alas, you've
> worn me down! Add the comments I mentioned above and I'd go along with
> it. 
> 
> Dominik: are you cool with this?

I agree with handling TMTA specially, as it uses such a different approach
to CPU frequency scaling _and_ gets TSC right. Therefore, ACK.

Thanks,
	Dominik