Re: [patch] prefer TSC over PM Timer

[dean gaudet]

On Mon, 15 Nov 2004, john stultz wrote:

> 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. 

i'm having a difficult time getting a centrino w/cpufreq to do anything 
bad with tsc while i'm imposing loads which cause the frequency to flutter 
around (i've got ondemand governor going).  maybe i need to do something 
more detailed like have ntp running against a solid time source while i do 
all these and let it run for longer to look for drift.  suggestions 
welcome.

> 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?

my patch lets you use "clock=pmtmr" if you want it.

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

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.


> > 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.

yeah that does sound unfortunate... it's almost like we should initialize 
timer_pm whenever it is there so it can be used for these calibration 
purposes.


> 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. 

i'm looking for a solution that generic distribution kernels can use...

honestly my selfish motivation is to get efficeon/crusoe treated properly 
-- they support a fixed TSC rate which does not vary with frequency (which 
many people fault us for, but the reality is that fixed TSC is the only 
viable solution for a processor which can vary power consumption without 
the involvement of the kernel).  i'd advocate a patch like the one 
below... but it feels wrong.

i suppose one way to solve all this is to punt the whole thing to userland
and let someone write a tool which either uses a database or runs code
to figure out which timer is best and sticks that into grub/lilo/whatever.

-dean


Signed-off-by: dean gaudet <dean@xxxxxxxxxx>

--- linux-2.6.10-rc2/arch/i386/kernel/timers/timer_pm.c.orig	2004-11-15 23:28:30.000000000 -0800
+++ linux-2.6.10-rc2/arch/i386/kernel/timers/timer_pm.c	2004-11-16 03:05:52.000000000 -0800
@@ -107,6 +107,13 @@
 	if (!cpu_has_tsc)
 		return -ENODEV;
 
+	/*
+	 * Transmeta CPUs have a fixed rate TSC, so prefer tsc
+	 * unless the user specifically requests pmtmr.
+	 */
+	if (!override[0] && boot_cpu_data.x86_vendor == X86_VENDOR_TRANSMETA)
+		return -ENODEV;
+
 	/* "verify" this timing source */
 	value1 = read_pmtmr();
 	for (i = 0; i < 10000; i++) {
-
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/