linux-2.6.0-test9-mm3_acpi-pm-monotonic-fix_A0

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

On Mon, 2003-11-17 at 15:46, Thomas Schlichter wrote:

> Well, but the sched_clock() -> monotonic_clock() patch seems to have a 
> problem...
> First, everything works smoothly if the PIT or the TSC clock are selected. (It 
> seems I cannot test the HPET timer due to missing hardware support)
> 
> But when booting with the PMTMR clock selected, my Interactivity test fails 
> again. :-( Maybe there is a problem in the PMTMR's monotonic clock part...?!

Good call! I was mis-adding in conversion to nanoseconds. The patch
below should fix it (Andrew, feel free to ignore this, I'll sync up all
the acpi-pm changes with you later). 

Although I'm finding that the sched_clock->monotonic_clock patch doesn't
look like a win. With that patch sched_clock takes ~400-700 cycles using
clock=pmtmr. With your "fix-sched_clock.diff" patch its less then 40
cycles. 

While better accuracy is nice, I can't imagine the 10-20x cost of
sched_clock is worth it. So I think your fix is the best solution.

thanks
-john


diff -Nru a/arch/i386/kernel/timers/timer_pm.c b/arch/i386/kernel/timers/timer_pm.c
--- a/arch/i386/kernel/timers/timer_pm.c	Tue Nov 18 14:17:27 2003
+++ b/arch/i386/kernel/timers/timer_pm.c	Tue Nov 18 14:17:27 2003
@@ -149,8 +149,8 @@
 	
 
 	/* convert to nanoseconds */
-	ret = base + ((this_offset - last_offset) & ACPI_PM_MASK);
-	ret = cyc2us(ret)*1000;
+	ret = ((this_offset - last_offset) & ACPI_PM_MASK);
+	ret = base + (cyc2us(ret)*1000);
 	return ret;
 }