lkml.org 
[lkml]   [2004]   [May]   [7]   [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
From
Date
On Fri, 2004-05-07 at 13:41, George Anzinger wrote:
> john stultz wrote:
> > On Thu, 2004-05-06 at 17:33, George Anzinger wrote:
> >
> >>john stultz wrote:
> >>
> >>>Roughly, I'd like to see the time code for all arches in 2.7 to look
> >>>like:
> >>>
> >>>u64 system_time /* NTP adjusted nanosecs since boot */
> >>>u64 wall_time_offset /* offset to system_time for time of day */
> >>>u64 offset_base /* last read raw hw value */
> >>
> >>Hm. In 2.6 we use an NTP adjusted wall time and a wall_to_monotonic offset. I
> >>don't really see the advantage here. Does this change buy us something?
> >>For what its worth, I introduced the wall_to_monotonic offset just because it
> >>was easier to do (and understand, I think) in the current kernel.
> >
> >
> > Well, in my opinion it seems much cleaner. Right now any time we adjust
> > xtime, we have to remember to adjust wall_to_monotonic. I believe we've
> > had issues where a change was made to just one and not the other.
> >
> > This is easier and has simpler rules. system_time always increments and
> > is only modified by the periodic time_interrupt_hook(). Then
> > wall_time_offset is only changes by do_settimeofday(). In fact, I hope
> > to make these values static to the time code, so that all in-kernel
> > users must go through the monotonic_clock() and do_gettimeofday()
> > interfaces.
>
> All that is fine for the kernel coder and such, but the fact remains that
> gettimeofday() is the BIG user and I keep seeing folks trying to make it faster.
> Also xtime.tv_sec is used a LOT in the kernel under the name: get_seconds().

<sigh> You're may be right. Having to convert from a u64 nanosec value
to a timeval in sys_gettimeofday() as well as get_seconds() may be a
performance problem. But I'm not completely convinced, as we already
have to play games shifting from timevals to timespecs and back. I'm not
sure the nsec/1000000 will kill us.

Pragmatically I'm willing to bend on that one by using timespecs instead
of u64s. But while I'm in the design phase, thinking of the problem as
juggling u64 nanoseconds simplifies it. Be it a u64 or a timespec, it
really doesn't change the design all that much. One you get to use "+"
and the other you use "time_add()".

thanks
-john



-
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:03    [W:0.264 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site