[lkml]   [2004]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: /proc or ps tools bug? 2.6.3, time is off
john stultz wrote:
> On Thu, 2004-02-26 at 16:20, George Anzinger wrote:
>>john stultz wrote:
>>>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?
>>Oops, I have been caught :) The above was composed in the email window. I
>>don't have a 2.6.x kernel up at the moment and I don't have any free cycles...
>>Late next week??
> Finally got a chance to go through my work queue and yikes! This is
> seriously stale! As neither George or I have come to bat with a patch,
> I'll attempt a swing.
> Albert/David: Would you mind testing the following to see if it resolves
> the issue for you?
> George: Mind skimming this to make sure its close enough to what you
> intended?

Looks rather like exactly what I intended.

> thanks
> -john
> diff -Nru a/include/linux/times.h b/include/linux/times.h
> --- a/include/linux/times.h Tue Apr 13 15:00:25 2004
> +++ b/include/linux/times.h Tue Apr 13 15:00:25 2004
> @@ -7,7 +7,12 @@
> #include <asm/param.h>
> #if (HZ % USER_HZ)==0
> -# define jiffies_to_clock_t(x) ((x) / (HZ / USER_HZ))
> +static inline long jiffies_to_clock_t(long x)
> +{
> + u64 tmp = (u64)x * TICK_NSEC;
> + x = do_div(tmp, (NSEC_PER_SEC / USER_HZ));
> + return (long)tmp;
> +}
> #else
> # define jiffies_to_clock_t(x) ((clock_t) jiffies_64_to_clock_t((u64) x))
> #endif

George Anzinger
Preemption patch:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:02    [W:0.101 / U:5.328 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site