High resolution timers

From RTwiki
(Difference between revisions)
Jump to: navigation, search
(high resolution timer patch was merged in v2.6.24-rc1)
 
(2 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
The [http://www.tglx.de/projects/hrtimers/ high resolution patch] is maintained by small group of core developers, led by [[User:Tglx|Thomas Gleixner]]. It allows precise timed scheduling and removes the dependency of timers on the periodic scheduler tick (jiffies). Thomas and Ingo wrote [[high resolution timer design notes]] which explain the implementation details.
 
The [http://www.tglx.de/projects/hrtimers/ high resolution patch] is maintained by small group of core developers, led by [[User:Tglx|Thomas Gleixner]]. It allows precise timed scheduling and removes the dependency of timers on the periodic scheduler tick (jiffies). Thomas and Ingo wrote [[high resolution timer design notes]] which explain the implementation details.
  
The high resolution timer patch is also integrated in the [[CONFIG_PREEMPT_RT_Patch|realtime preemption patch]] and was submitted for mainline integration recently.
+
Since 2.6.24-rc1 the high resolution timer patch are fully merged and so the project is in "history mode".
 +
 
 +
Historically the high resolution timer patch was also integrated in the [[CONFIG_PREEMPT_RT_Patch|realtime preemption patch]].
  
 
== How to use high resolution timers ? ==
 
== 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.
 
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.
 
There are patches in preparation to extend this to poll and select syscalls.
 
  
 
== Dynamic priority support for high resolution timers (extension available in the realtime preemption patch) ==
 
== 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 seperated in the realtime preemption patch a while ago. While this separation enhanced the behaviour 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 reimplement 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.
+
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 behaviour 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 reimplement 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.
 
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.

Latest revision as of 09:19, 2 May 2008

[edit] High resolution timers

The high resolution patch is maintained by small group of core developers, led by Thomas Gleixner. It allows precise timed scheduling and removes the dependency of timers on the periodic scheduler tick (jiffies). Thomas and Ingo wrote high resolution timer design notes which explain the implementation details.

Since 2.6.24-rc1 the high resolution timer patch are fully merged and so the project is in "history mode".

Historically the high resolution timer patch was also integrated in the realtime preemption patch.

[edit] 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.

[edit] 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 behaviour 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 reimplement 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.

Personal tools