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

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

 



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