Fix jiffies_to_time[spec | val] and converse to use actual jiffies increment rather than 1/HZ

In the current system (2.5.67) time_spec to jiffies, time_val to jiffies and the converse (jiffies to time_val and jiffies to time_spec) all use 1/HZ as the measure of a jiffie. Because of the inability of the PIT to actually generate an accurate 1/HZ interrupt, the wall clock is updated with a more accurate value (999848 nanoseconds per jiffie for HZ = 1000). This causes a 1/HZ interpretation of jiffies based timing to run faster than the wall clock, thus causing sleeps and timers to expire short of the requested time. Try, for example:

time sleep 60

This patch changes the conversion routines to use the same value as the wall clock update code to do the conversions.

The actual math is almost all done at compile time. The run time conversions require little if any more execution time.

This patch must be applied after the patch I posted earlier today which fixed the CLOCK_MONOTONIC resolution issue.

George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

diff -urP -I '\$Id:.*Exp \$' -X /usr/src/patch.exclude linux-2.5.67-bk3-mono/include/asm-i386/div64.h linux/include/asm-i386/div64.h
@@ -14,4 +14,22 @@
 	__mod; \
 })
 
+/*
+ * (long)X = ((long long)divs) / (long)div
+ * (long)rem = ((long long)divs) % (long)div
+ *
+ * Warning, this will do an exception if X overflows.
+ */
+#define div_long_long_rem(a,b,c) div_ll_X_l_rem(a,b,c)
+
+extern inline long
+div_ll_X_l_rem(long long divs, long div, long *rem)
+{
+	long dum2;
+      __asm__("divl %2":"=a"(dum2), "=d"(*rem)
+      :	"rm"(div), "A"(divs));
+
+	return dum2;
+
+}
 #endif

diff -urP -I '\$Id:.*Exp \$' -X /usr/src/patch.exclude linux-2.5.67-bk3-mono/include/linux/timex.h linux/include/linux/timex.h
@@ -51,7 +51,6 @@
 #ifndef _LINUX_TIMEX_H
 #define _LINUX_TIMEX_H
 
-#include <linux/time.h>
 #include <asm/param.h>
 
 /*

@@ -177,6 +176,7 @@
 /* a value TUSEC for TICK_USEC (can be set bij adjtimex)		*/
 #define TICK_NSEC(TUSEC) (SH_DIV (TUSEC * USER_HZ * 1000, ACTHZ, 8))
 
+#include <linux/time.h>
 /*
  * syscall interface - used (mainly by NTP daemon)
  * to discipline kernel clock oscillator

Binary files linux-2.5.67-bk3-mono/usr/initramfs_data.cpio and linux/usr/initramfs_data.cpio differ Binary files linux-2.5.67-bk3-mono/usr/initramfs_data.cpio.gz and linux/usr/initramfs_data.cpio.gz differ

There's an increasing amount of 64-bit math appearing here, which gcc has been historically bad with. Is there any chance that all this extra complexity can vanish for architectures which do not have this problem?

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

I suppose that is possible. On the other hand, the only 64-bit things we leave to C are the "+" and shift.

George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml