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

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

On Thu, 2004-02-26 at 15:06, George Anzinger wrote:
> john stultz wrote:
> > 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. 
> 
> More or less.  I wonder if:

> static inline long jiffies_to_clock_t(long x)
> {
> 	u64 tmp = (u64)x * TICK_NSEC;
> 	div64(tmp, (NSEC_PER_SEC / USER_HZ));
> 	return (long)x;
> }
> might be better as it addresses the overflow issue.  Should be able to toss the 
> #if (HZ % USER_HZ)==0 test too.  We could get carried away and do scaled math to 
> eliminate the div64 but I don't think this path is used enough to justify the 
> clarity ;) that would make.

Sounds good to me. Would you mind sending the diff so Petri and David
could test it?

thanks
-john