[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.029 / U:25.192 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site