Re: [patch 00/21] hrtimer - High-resolution timer subsystem

[George Anzinger]

Thomas Gleixner wrote:
~
> > I wouldn't say a 1 day interval timer is a very realistic example and the 
> > old timer wouldn't be very precise for this.
>
>
> Sure, as all comparisons are flawed. I just used a simple example to
> illustrate my POV.
>
>
> > The rationale for example talks about "a periodic timer with an absolute 
> > _initial_ expiration time", so I could also construct a valid example with 
> > this expectation. The more I read the spec the more I think the current 
> > behaviour is not correct, e.g. that ABS_TIME is only relevant for 
> > it_value.
> > So I'm interested in specific interpretations of the spec which support 
> > the current behaviour.

My $0.02 worth: It is clear (from the standard) that the initial time 
is to be ABS_TIME.  It is also clear that the interval is to be added 
to that time.  IMHO then, the result should have the same property, 
i.e. ABS_TIME.  Sort of like adding an offset to a relative address. 
The result is still relative.
> Unfortunately you find just the spec all over the place. I fear we have
> to find and agree on an interpretation ourself.
>
> I agree, that the restriction to the initial it_value is definitely
> something you can read out of the spec. But it does not make a lot of
> sense for me. Also the restriction to TIMER_ABSTIME is somehow strange
> as it converts an CLOCK_REALTIME timer to a CLOCK_MONOTONIC timer. I
> never understood the rationale behind that.

I don't think it really does that.  The TIMER_ABSTIME flag just says 
that the time requested is to be taken as "clock" time (which ever 
clock) AND that this is to be the expire time regardless of clock 
setting.  We, in an attempt to simplify the lists, convert the expire 
time into some common time notation (in most cases we convert relative 
times to absolute times) but this introduces problems because the 
caller has _asked_ for a relative or absolute time and not the other. 
 If the clock can not be set this is not a problem.  If it can, well, 
we need to keep track of what the caller wanted, absolute or relative.

It might help others to understand this if you were to remove the 
clock names from your queues and instead call them "absolute_real" and 
"up_time".  Then it would be more clear, I think, that we are mapping 
user requests onto these queues based on the desired functionality 
without a predilection to put a timer on a given queue just because a 
particular clock was requested.  At this point it becomes clear, for 
example, that a TIMER_ABSTIME request on the real clock is the _only_ 
request that should be mapped to the "absolute_real" list.
>
~
--
George Anzinger   george@xxxxxxxxxx
HRT (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/