Messages in this thread | | | Date | Fri, 07 May 2004 13:41:42 -0700 | From | George Anzinger <> | Subject | Re: /proc or ps tools bug? 2.6.3, time is off |
| |
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(). ~> -- 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/
| |