From: George Anzinger <george@mvista.com>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org, mingo@elte.hu,
akpm@osdl.org, johnstul@us.ibm.com, paulmck@us.ibm.com
Subject: Re: [ANNOUNCE] ktimers subsystem
Date: Mon, 19 Sep 2005 17:43:05 -0700 [thread overview]
Message-ID: <432F5B19.4050105@mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0509191500040.27238@schroedinger.engr.sgi.com>
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 continuous 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.
Why is this astonishing? What it really indicates is the nature of
Linux where in we have just (with 2.6) introduced the concept of
monotonic time. As such, and with few users, it made a LOT of sense to
not upset too much code by making it the primary clock. In the end, the
difference between the two clocks is a constant offset and it is only an
add in one path or the other.
An argument from the other side is that ntp works with CLOCK_REALTIME
and so that is where and what it corrects.
Agreed, this can be turned around, however, one needs folks like John
Stultz who take the time to understand ntp as well as all the other
clock issues to turn things like this around. Still, we should consider
carefully IF we want to turn it around.
A far more astonishing thing, IMHO, is the cascade in the timers code...
>
>
> 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.
> -
Both sides of this argument have merit. Much as we would like to, we
can not change user usage. AND, in the end, they are, and will continue
to make far more calls to get the time than the kernel does. So, in raw
cpu power (or time) consumed, the user get time will win over kernel
usage. Also, the time to do a gettimeofday is easily computed with the
most simple program...
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
next prev parent reply other threads:[~2005-09-20 0:44 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-19 16:48 [ANNOUNCE] ktimers subsystem tglx
2005-09-19 16:48 ` [PATCH] " tglx
2005-09-19 21:47 ` [ANNOUNCE] " Thomas Gleixner
2005-09-19 22:03 ` Christoph Lameter
2005-09-19 22:17 ` Thomas Gleixner
2005-09-19 22:24 ` Christoph Lameter
2005-09-19 22:44 ` Thomas Gleixner
2005-09-19 22:50 ` john stultz
2005-09-19 22:58 ` Thomas Gleixner
2005-09-19 23:04 ` Christoph Lameter
2005-09-19 23:12 ` Thomas Gleixner
2005-09-20 7:14 ` Ingo Molnar
2005-09-20 7:10 ` Ingo Molnar
2005-09-21 19:24 ` Pavel Machek
2005-09-19 22:39 ` Christopher Friesen
2005-09-19 22:54 ` Thomas Gleixner
2005-09-20 4:57 ` Christopher Friesen
2005-09-20 5:11 ` Thomas Gleixner
2005-09-20 0:43 ` George Anzinger [this message]
2005-09-21 19:50 ` Roman Zippel
2005-09-21 22:41 ` Thomas Gleixner
2005-09-22 12:59 ` Ingo Molnar
2005-09-22 23:09 ` Roman Zippel
2005-09-22 23:31 ` Christopher Friesen
2005-09-23 0:25 ` Roman Zippel
2005-09-23 6:49 ` Thomas Gleixner
2005-09-24 3:15 ` Roman Zippel
2005-09-24 5:16 ` Ingo Molnar
2005-09-24 10:35 ` Roman Zippel
2005-09-24 13:56 ` Thomas Gleixner
2005-09-24 16:51 ` Daniel Walker
2005-09-24 23:45 ` Roman Zippel
2005-09-25 21:00 ` Thomas Gleixner
2005-09-27 16:54 ` Roman Zippel
2005-09-27 19:03 ` Tim Bird
2005-09-28 16:36 ` Roman Zippel
2005-09-25 21:02 ` Thomas Gleixner
2005-09-27 16:48 ` Roman Zippel
2005-09-27 18:38 ` Tim Bird
2005-09-27 20:36 ` George Anzinger
2005-09-23 2:25 ` john stultz
2005-09-23 8:27 ` Thomas Gleixner
2005-09-24 2:43 ` Roman Zippel
2005-09-24 5:03 ` Ingo Molnar
2005-09-24 9:04 ` James Bruce
2005-09-23 15:21 ` Paul E. McKenney
2005-09-24 3:38 ` Roman Zippel
-- strict thread matches above, loose matches on Subject: below --
2005-09-25 15:48 Sid Boyce
2005-09-25 18:20 ` Zwane Mwaikambo
2005-09-26 0:02 ` Sid Boyce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=432F5B19.4050105@mvista.com \
--to=george@mvista.com \
--cc=akpm@osdl.org \
--cc=clameter@engr.sgi.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@us.ibm.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox