Re: /proc or ps tools bug? 2.6.3, time is off

[john stultz <johnstul@us.ibm.com>]

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. 

To be brutal, I'd like to see xtime killed completely. Jiffies and HZ
too, although I'd be happy with those two being made static to the
interval timer code. There are too many places where folks have tried to
extrapolate a time value from some global accounting variable, and w/ HZ
not quite being exactly 1000 now on i386, all that code is just slightly
wrong. Its spaghetti code now, and we just need to put that mess behind
a few clean understandable interfaces.  

But hey, that's me dreaming, I'm sure there will be some reason odd
someone will need to get into the guts of the time code and we'll have
to break the opacity. :)

And I do realize we'll also need a get_timestamp() or something that
will quickly return a low-res timestamp like the current value of
system_time. I don't intend for all those users of xtime or jiffies to
really go out and hit hardware to calculate a nanosecond accurate time
value. 

> > And ignoring the magic NTP_GUNK macros, that's all there is to it
> > (Although don't kid your self, the NTP_GUNK is nasty). 
> 
> Right, and it needs to be recast to use secs and nanosecs...  

Yea, yea, you're right. u64 nanosecond values are just so much simpler
to work with, until you hit the NTP code. 

> But you forget the 
> accounting code which needs the periodic interrupt to charge time to whom ever.

True, although I'd like to avoid doing that in the time subsystem.
Instead the interval timer subsystem would run the accounting code,
which would then call get_timestamp() to calculate the amount of time to
charge a process. 

thanks
-john