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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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   [email protected]
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux