[lkml]   [2005]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ANNOUNCE] ktimers subsystem
On Mon, 2005-09-19 at 15:03 -0700, Christoph Lameter wrote:
> On Mon, 19 Sep 2005 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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-20 00:19    [W:0.291 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site