Re: /proc or ps tools bug? 2.6.3, time is off

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

On Wed, 2004-02-25 at 13:10, George Anzinger wrote:
> Albert Cahalan wrote:
> > This is NOT sane. Remeber that procps doesn't get to see HZ.
> > Only USER_HZ is available, as the AT_CLKTCK ELF note.
> > 
> > I think the way to fix this is to skip or add a tick
> > every now and then, so that the long-term HZ is exact.
> > 
> > Another way is to simply choose between pure old-style
> > tick-based timekeeping and pure new-style cycle-based
> > (TSC or ACPI) timekeeping. Systems with uncooperative
> > hardware have to use the old-style time keeping. This
> > should simply the code greatly.
> 
> On checking the code and thinking about this, I would suggest that we change 
> start_time in the task struct to be the wall time (or monotonic time if that 
> seems better).  I only find two places this is used, in proc and in the 
> accounting code.  Both of these could easily be changed.  Of course, even 
> leaving it as it is, they could be changed to report more correct values by 
> using the correct conversions to translate the system HZ to USER_HZ.

Is this close to what your thinking of? 
I can't reproduce the issue on my systems, so I'll need someone else to
test this. 

thanks
-john

--- 1.5/include/linux/times.h	Sun Nov  9 19:26:08 2003
+++ edited/include/linux/times.h	Wed Feb 25 17:39:11 2004
@@ -7,7 +7,7 @@
 #include <asm/param.h>
 
 #if (HZ % USER_HZ)==0
-# define jiffies_to_clock_t(x) ((x) / (HZ / USER_HZ))
+# define jiffies_to_clock_t(x) (((x*TICK_NSEC*HZ)/NSEC_PER_SEC) / (HZ / USER_HZ))
 #else
 # define jiffies_to_clock_t(x) ((clock_t) jiffies_64_to_clock_t((u64) x))
 #endif