Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
======How to use high resolution timers?======

There are no special requirements, except a recent glibc, to make use of high resolution timers. When the high resolution timers are enabled in the Linux kernel, then nanosleep, itimers and posix timers provide the high resolution mode without changes to the source code.
Dynamic priority support for high resolution timers (extension available in the realtime preemption patch)

When realtime preemption is enabled, the delivery of signals at the expiry of itimer and posix interval timers can not be done in the hard interrupt context of the high resolution timer interrupt. The signal delivery must happen in thread context due to locking constraints. To avoid long latencies the softirq threads have been separated in the realtime preemption patch a while ago. While this separation enhanced the behavior significantly, there was still a problem remaining. The hrtimers softirq thread can be arbitrarily long delayed by higher priority tasks. A possible solution is to up the priority of the hrtimer softirq thread, but this has the effect that all timer related signals are delivered at high priority and therefore introduce latency impacts to high priority tasks. A prior version of the realtime preemption patch contained a solution for this problem already: dynamic adjustment of the softirq priority depending on the priority of the task for which the signal has to be delivered. 

This functionality was removed with the rework of the high resolution timer patches and due to a subtle race condition with the Priority Inheritance code. The new design of RT-Mutexes and the core PI support in the scheduler removed this race condition and allowed to re-implement this feature. On a PentiumIII 400 MHz test machine this change reduced the maximum user space latency for a thread waiting on the delivery of a periodic signal significantly from ~400 to ~90 micro seconds under full system load.

Note that (clock_)nanosleep functions do not suffer from this problem as the wakeup function at timer expiry is executed in the context of the high resolution timer interrupt. If an application is not using asynchronous signal handlers, it is recommended to use the clock_nanosleep() function with the TIMER_ABSTIME flag set instead of waiting for the periodic timer signal delivery. The application has to maintain the absolute expiry time for the next interval itself, but this is a lightweight operation of adding and normalizing two struct timespec values. The benefit is significantly lower maximum latencies (~50us) and less OS overhead in general.

Further information:
  * [[https://docs.kernel.org/timers/hrtimers.html|hrtimers - subsystem for high-resolution kernel timers]]
  * [[https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/hrtimer.h|include/linux/hrtimer.h]]
  * [[https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/kernel/time/hrtimer.c|kernel/time/hrtimer.c]]
  * 💾 //Historical//: [[https://docs.kernel.org/timers/highres.html|High resolution timers and dynamic ticks design notes]]
Wiki

User Tools

Site Tools

Page Tools
