Re: [RFC][PATCH] new timeofday core subsystem (v. A3)

[George Anzinger]

john stultz wrote:
> On Mon, 2005-03-14 at 21:37 -0800, Christoph Lameter wrote:
>
> > Note that similarities exist between the posix clock and the time sources.
> > Will all time sources be exportable as posix clocks?
>
>
> At this point I'm not familiar enough with the posix clocks interface to
> say, although its probably outside the scope of the initial timeofday
> rework.

I do think we need to consider the needs of that subsystem.  Clock wise, it 
makes a monotonic and a real time clock available to the user.  The real time 
clock is just a timespec version of the timeval gettimeofday clock.  At the 
current time, the monotonic clock is the real time clock plus wall_to_monotonic. 
 All that is rather simple and straight forward, an I don't recommend adding 
any other clocks unless there is a real need.

The interesting thing is that the posix timers are based on the posix clocks 
which are base on wall_clock, and the jiffies clock which is what runs the 
timers.  In order to make sense of timer requests it is neccessary to, 
atomically, grab all three clocks (i.e. wall_clock aka gettimeofday, 
wall_to_monotonic, and jiffies with the jiffies offset).  The code can then 
figure out when a timer needs to expire in jiffies time in order to expire at a 
given wall or monotonic time.  Currently the xtime_time sequence lock is used to 
do this.

Another issue that posix timers brings forward is the need to know when the 
clock is set.  This is needed to cause timers that were requested to expire at 
some absolute wall_time to do so even if time is set while they are running.  A 
word on how this is done is in order...

Since the processing of a clock set by the posix timers code may, in fact, allow 
the time to be set more than once before the affected timers are adjusted (or 
rather to avoid the locking rats nest not allowing this would cause), the 
wall_to_monotonic value is exploited.  In particular, a clock setting changes 
this value by the exact amount that time was adjusted.  So, each posix timer 
carries the value of wall_to_monotonic that was in use when the timer was 
started.  The clock_was_set code uses this to compute the clock movement and 
thus the adjustment needed to make the timer expire at the right time.

What this translates to in the new code is a) the need for a way to atomically 
get all the key times (wall, monotonic, jiffie) and b) access to a value that 
will allow it to compute the amount of time a clock set, or a series of clock 
settings, changed time by.  Of course, it also needs the clock_was_set() notify 
call.
> Do you have a link that might explain the posix clocks spec and its
> intent?

Well, there is my signature :)  Really, on the high-res-timers project site you 
want to download the support patch.  In there, among other things, is a set of 
man pages on posix clocks & timers.  The patch applies to any kernel and just 
adds a new set of directories off of Documentation.
--
George Anzinger   george@xxxxxxxxxx
High-res-timers:  http://sourceforge.net/projects/high-res-timers/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/