Re: [patch] prefer TSC over PM Timer

[john stultz <johnstul@us.ibm.com>]

On Mon, 2004-11-15 at 16:23, dean gaudet wrote:
> i've heard other folks have independently run into this problem -- in fact 
> i see the most recent fc2 kernels already do this.  i'd like this to be 
> accepted into the main kernel though.
> 
> the x86 PM Timer is an order of magnitude slower than the TSC for 
> gettimeofday calls.  i'm seeing 8%+ of the time spent doing gettimeofday 
> in someworkloads... and apparently kernel.org was seeing 80% of its time 
> go to gettimeofday during the fc3-release overload.  PM timer is also less 
> accurate than TSC.
> 
> i can see a vague argument around cpufreq / tsc troubles, but i'm having a 
> hell of a time getting a centrino box to show any TSC troubles even while 
> i induce workloads that cause cpufreq to bounce the frequency around.  
> maybe someone could give an example of it failing...

I understand your frustration. 

While there are a great number of systems that can use the TSC, cpufreq
scaling laptops, and a number of SMP and NUMA systems cannot use it as a
time source. Additinoally its difficult to detect when its wrong as
there are a reasonable number of systems that frequently miss timer
ticks. Although it is much slower, ACPI PM is just more reliable across
the broad spectrum of systems. 

With your patch, ACPI PM would never be selected (as TSC always wins
when available, and it will be available on all ACPI enabled i386
systems). So its just the same as disabling CONFIG_X86_PM_TIMER, so why
not just do that?

Do note, using the "clock=tsc" boot option, you can easily force the
system to use the TSC.

> note:  when timer_tsc discovers inaccuracy after boot it falls back to 
> timer_pit ... timer_pit is twice as expensive as timer_pm, and it'd be 
> cool if timer_tsc could fall back to timer_pm... but by that point in time 
> all the __init stuff is gone, so i can't see how to init timer_pm.  this 
> would be a more ideal solution.

Well, the lost-ticks/pit fallback code isn't all that robust. We have
two unreliable time sources where we try to sort out which one is wrong
by using the other. I worry we'd have to implement something like NTP in
the kernel in order to correctly choose the best working time source.

I would however, support a patch that selected the TSC over the ACPI PM
time source when CONFIG_CPUFREQ and CONFIG_SMP were N. That's fairly
safe. 

thanks
-john