Messages in this thread |  | | | Subject | Re: [ANNOUNCE] ktimers subsystem | | From | Thomas Gleixner <> | | Date | Tue, 20 Sep 2005 00:17:12 +0200 |
| |
On Mon, 2005-09-19 at 15:03 -0700, Christoph Lameter wrote: > On Mon, 19 Sep 2005 tglx@linutronix.de wrote: > > > sources. Another astonishing implementation detail of the current time > > keeping is the fact that we get the monotonic clock (defined by POSIX as > > a continous clock source which can not be set) by subtracting a variable > > offset from the real time clock, which can be set by the user and > > corrected by NTP or other mechanisms. > > The benefit or drawback of that implementation depends which time is more > important: realtime or monotonic time. I think the most used time value is > realtime and not monotonic time. Having the real time value in xtime > saves one addition when retrieving realtime.
Thats only partially true.
Granted, the most used time in user space is clock_realtime (gettimeofday() / clock_gettime(CLOCK_REALTIME).
But do we really want to discuss one add instruction ?
The most used time in kernel space is clock_monotonic. Thats partially a result of the rather odd POSIX specs regarding relative CLOCK_REALTIME timers.
Also the basic prerequisite for for high resolution timers is a fast and simple access to clock_monotonic rather than to a backward corrected clock_realtime representation.
Kernel code speed in hot pathes must have precedence over code executed on behalf of userspace if its not completely out of bounds. One add/sub is definitely not.
We should rather ask glibc people why gettimeofday() / clock_getttime() is called inside the library code all over the place for non obvious reasons.
tglx
- 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/
|  |