Messages in this thread | | | Subject | Re: /proc or ps tools bug? 2.6.3, time is off | From | john stultz <> | Date | Thu, 26 Feb 2004 15:10:18 -0800 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |