lkml.org 
[lkml]   [2004]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: /proc or ps tools bug? 2.6.3, time is off
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??
>

--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

-
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/

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