Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5

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

 



Roman Zippel wrote:
Hi,

On Tue, 11 Oct 2005, Thomas Gleixner wrote:


As far as I understand SUS timer resolution is equal to clock resolution
and the timer value/interval is rounded up to the resolution.

Please check the rationale about clocks and timers. It talks about clocks and timer services based on them and their resolutions can be different.

Well, yes and no. Under timer_settime() it talks about ticks and resolution being the inverse of the tick rate. AND it does imply that timers on a given CLOCK will have that clocks resolution as returned by clock_res(). This is fine as far as it goes. In practical systems we almost always have a much higher resolution for the clock_gettime() and gettimeofday() than the tick rate. What the standard does not seem to want to do is to admit that a clock may have the ability to be read at a better resolution than its tick rate.

For this reason, the usual practice is to return the "timer" resolution for clock_res() and to return clock values with as much resolution as possible. In no case should the actual clock resolution be less than what clock_res() returns.


clock_settime():
... Time values that are between two consecutive non-negative integer
multiples of the resolution of the specified clock shall be truncated
down to the smaller multiple of the resolution.

timer_settime():
...Time values that are between two consecutive non-negative integer
multiples of the resolution of the specified timer shall be rounded up
to the larger multiple of the resolution. Quantization error shall not
cause the timer to expire earlier than the rounded time value.

Here the standard uses "resolution of the specified timer" but the only way, in the standard, to associate a resolution with a timer is via the CLOCK used.


Where does it say anything about that their resolution is equal?

So the timers resolution is the same as the CLOCKs resolution as returned by clock_res() but, as I said above, the usual practice is to return clock values (via clock_gettime or gettimeofday) with higher resolution.


Reprogramming interval timers by now + interval is completely wrong.
Reprogramming has to be timer->expires + interval and nothing else.

Where do get the requirement for an explicit rounding from?
The point is that the timer should not expire early, but there is more than one way to do this and can be done implicitly using the timer resolution.

See above.

The standard requires that timer expiry times and interval times be rounded up to the next "resolution" value. For the first or initial time of a repeating timer we, usually, have to add an additional "resolution" to account for starting the timer at some point between ticks. For the interval on repeating timers, we know that the interval is starting at the last expiry time and thus do not need to account for the between tick start time.

~

--
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