lkml.org 
[lkml]   [2004]   [Apr]   [13]   [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 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.

    -g
    >
    > 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 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:02    [W:0.049 / U:0.888 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site