[lkml]   [2004]   [Feb]   [26]   [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 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
    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:01    [W:0.049 / U:10.500 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site