Types of Timers
The timing subsystem of the kernel has grown tremendously during the development of 2.6. For the initial releases, the timer subsystem consisted solely of what are now known as low-resolution timers. Essentially, low-resolution timers are centered around a periodic tick which happens at regular intervals. Events can be scheduled to be activated at one of these intervals. Pressure to extend this comparatively simple framework came predominantly from two sources:
□ Devices with limited power (i.e., laptops, embedded systems, etc.) need to use as little energy as possible when there is nothing to do. If a periodic clock is running, there is, however, nearly always something to do — the tick must be provided. But if no users for the tick are present, it would basically not need to run. Nevertheless, the system needs to be brought from a low-power state into a state with higher power consumption just to implement the periodic tick.
□ Multimedia-oriented applications need very precise timekeeping, for instance, to avoid frame skips in videos, or jumps during audio playback. This necessitated increasing the available resolution.
Finding a good solution agreeable to all developers (and users!) who come into contact with time management — and there is quite a large number of them — took many years and a good many proposed patches. The current state is rather unusual because two rather distinct types of timers are supported by the kernel:
□ Classical timers have been available since the initial versions of the kernel. Their implementation is located in kernel/timer.c. A resolution of typically 4 milliseconds is provided, but the value depends on the frequency with which the machine's timer interrupt is operated. These classical timers are called low-resolution or timer wheel timers.
□ For many applications, especially media-oriented ones, a timer resolution of several milliseconds is not good enough. Indeed, recent hardware provides means of much more precise timing, which can achieve resolutions in the nanosecond range formally. During the development of kernel 2.6, an additional timer subsystem was added allowing the use of such timer sources. The timers provided by the new subsystem are conventionally referred to as high-resolution timers.
Some code for high-resolution timers is always compiled into the kernel, but the implementation will only perform better than low-resolution timers if the configuration option high_res_timers is set. The framework introduced by high-resolution timers is reused by low-resolution timers (in fact, low-resolution timers are implemented on top of the high-resolution mechanism).
Classical timers are bound by a fixed raster, while high-resolution clock events can essentially happen at arbitrary times; see Figure 15-1. Unless the dynamic ticks feature is active, it can also happen that ticks occur when no event expires. High-resolution events, in contrast, only occur when some event is due.
Time ® events
I Tick w/o events
* 1 ■ ■■• ■ -I ■ . High resolution
Jiffie 1234 1235 1236 1237 1238 1239 event
Figure 15-1: Comparison between low- and high-resolution timers.
Why did the developers not choose the seemingly obvious path and improve the already existing timer subsystem, but instead added a completely new one? Indeed, some people tried to pursue this strategy, but the mature and robust structure of the old timer subsystem did not make it particularly easy to improve while still being efficient — and without creating new problems. Some more thoughts on this problem can be found in Documentation/hrtimers.txt.
Independent of the resolution, the kernel nomenclature distinguishes two types of timers:
□ Time-outs — Represent events that are bound to happen after some time, but can and usually will be canceled before. For example, consider that the network subsystem waits for an incoming packet that is bound to arrive within a certain period of time. To handle this situation, a timer is set that will expire after the time is over. Since packets usually arrive on time, chances are that the timer will be removed before it will actually go off. Besides resolution is not very critical for these types of timers. When the kernel allows an acknowledgment to a packet to be sent within 10 seconds, it does not really matter if the time-out occurs after 10 or 10.001 seconds.
□ Timers — Are used to implement temporal sequences. For instance, a sound card driver could want to issue some data to a sound card in small, periodic time intervals. Timers of this sort will usually expire and require much better resolution than time-outs.
An overview of the building blocks employed to implement the timing subsystem is given in Figure 15-2. Owing to the nature of an overview, it is not too precise, but gives a quick glance at what is involved in timekeeping, and how the components interact with each other. Many details are left to the following discussion.
Hardware clock chips
Figure 15-2: Overview of the components that build up the timing subsystem.
The raw hardware sits at the very bottom. Every typical system has several devices, usually implemented by clock chips, that provide timing functionality and can serve as clocks. Which hardware is available depends on the particular architecture. IA-32 and AMD64 systems, for instance, have a programmable interrupt timer (PIT, implemented by the 8253 chip) as a classical clock source that has only a very modest resolution and stability. CPU-local APICs (advanced programmable interrupt controllers), which were already mentioned in the context of IRQ handling, provide much better resolution and stability. They are suitable as high-resolution time sources, whereas the PIT is only good enough for low-resolution timers.
Hardware naturally needs to be programmed by architecture-specific code, but the clock source abstraction provides a generic interface to all hardware clock chips. Essentially, read access to the current value of the running counter provided by a clock chip is granted.
Periodic events do not comply with a free running counter very well, thus another abstraction is required. Clock events are the foundation of periodic events. Clock events can, however, be more powerful. Some time devices can provide events at arbitrary, irregular points in time. In contrast to periodic event devices, they are called one-shot devices.
The high-resolution timer mechanism is based on clock events, whereas the low-resolution timer mechanism utilizes periodic events that can either come directly from a low-resolution clock or from the highresolution subsystem. Two important tasks for which low-resolution timers assume responsibility are
1. Handle the global jiffies counter. The value is incremented periodically (or at least it looks periodical to most parts of the kernel) and represents a particularly simple form of time reference.1
2. Perform per-process accounting. This also includes handling classical low-resolution timers, which can be associated with any process.
Continue reading here: Configuration Options
Was this article helpful?