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

[George Anzinger <george@mvista.com>]

Roman Zippel wrote:
> 
> 
> Could you explain a little the resolution handling behind in your patch?
> If I read SUS correctly clock resolution and timer resolution don't have 
> to be the same, the first is returned by clock_getres() and the latter 
> only documented somewhere (and AFAICT our implementation always returned 
> the wrong value).
> IMO this also means we can don't have to make the rounding that 
> complicated. Actually it could be done automatically by the timer, e.g. 
> interval timer are reprogrammed at (now + interval) and the timer 
> resolution will automatically round it up.

As I understand it the resolution should apply to timers assigned to the given clock.  I assume most 
clock reads will return the best resolution possible, but we can only know what that is (in user 
land) by looking at at series of clock reads and making an educated guess (if indeed we care).

For timers, on the other hand, resolution serves two purposes: a) it tells the user/ application 
what to expect and allows him to take evasive action (such as asking for the timer to expire a "res" 
amount sooner) to get what he wants/needs.  b) for the kernel, it allows timers to be grouped such 
that we can limit the number of interrupts we need to service to handle timers.  Some of this might 
be possible by relying on the hardware, but a lot of hardware may actually be able to handle 
nanosecond resolution.  At that point you end up grouping by latency and getting to the point were, 
for no good reason, you have the possibility of timer storms.  For no good reason, i.e. the user 
really doesn't need or want that level of resolution, being happy with, for example 10 microseconds 
or some such.  This is why, in the HRT patch, the same can be said of the new ability to set HZ at 
configure time.
> 
> 

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/