Analysis of time programming and realization principle in Linux (Iv.) the work of Linux kernel

Review

In recent years, with the widespread use of Linux, time programming has put forward higher requirements. Real-time applications, multimedia software for the clock and timer precision requirements, in the early Linux kernel, the timer can support the highest precision is a tick. To improve clock accuracy, one can only improve the HZ value of the kernel (a kernel parameter that represents the frequency at which the kernel clock interrupts). The higher HZ value means that the clock interrupts more frequently, and the kernel spends more time on the clock processing. And any work of the kernel is simply a useless expense for the application. When the HZ value is increased to 1000, Linux availability will decrease if you continue to improve.

On the other hand, we have seen that system hardware such as Hpet (High Precision Event Timer) has been able to provide nanosecond-level clock outages, and how to use these high-precision clock hardware to provide more accurate timing services is the main topic of this section.

New changes since the 2.6.16

Before 2.6.16, Linux developers spent a lot of effort trying to achieve high-precision clocks in the original code architecture, but this effort proved futile.

So from 2.6.16, the Ingo molar and Thomas Gleixner of RedHat company have made a great reconstruction of the time system. The following new modules are introduced:

Generic Timer Framework

The early Linux kernel also needed to support many different clock hardware devices, but the kernel itself was relatively simple to use for these devices. The kernel encapsulates the different operations of the hardware in the Arch layer. For example, under the x86 architecture, the set PIT (programmable Interrupt Timer) was completed when the 8259 chip was initialized, the API name called Setup_pit_timer (), and in other architectures, no 8259, initialization The specific implementations in Time_init () are different, and the data structures that represent the Timer hardware are named and different by the API. Since early Linux requires only a clock initialization and limited number of times to operate specific hardware, the different architectures are not problematic with different implementation details.

The new kernel supports the tickless mode, which shuts down the clock when the kernel is idle to save power. For this reason, the kernel requires frequent operation of the Timer hardware, in which case the adoption of a unified abstraction layer facilitates the maintenance of the code. This is the Generic Timer Frame, which abstracts the various hardware into three unified data structures:

Clock Source, expressed by struct Clocksource. This data structure is primarily used to abstract the system hardware that provides timing capabilities, such as the RTC (real time Clock), the TSC (Time Stamp Counter), and so on.

Clock Event Device, expressed by struct clock_event_device. This data structure is mainly used to encapsulate and abstract the system hardware, such as Hpet, which can provide the ability of timing interruption.

Tick Device, expressed by struct tick_device. This data structure is built on top of the clock event device and is designed to represent the devices that produce tick. Tick is a timed outage. So ultimately, a Clock event Device is required to complete, but Clock event Device can be used not only to provide tick, but also to provide additional functionality in high precision Timer mode.

The Generic Timer Frame separates the different hardware of the time from the top software, allowing the time system to easily support new clock hardware without having to modify the hardware-independent code in large numbers.

High-precision Timer Hrtimer (high resolution timer)

The high precision clock can not be built on the existing time wheel algorithm, although the time wheel is an effective management data structure, but its cascades operation has unpredictable delay. It is better suited to a low precision timer, called the "timeout" type, that is, a timer that is canceled without triggering. In this case, cascades may cause the clock due to delay without any adverse effect, because there is no cascades, in other words, most Timer does not trigger the Cascades operation. Users of high-precision timers often need to wait for them to be accurately triggered to perform time-sensitive tasks. Therefore, the delay caused by the Cascades operation is unacceptable. So the kernel developer had to abandon the time wheel algorithm and seek other high-precision clock algorithms instead. Finally, the developer chooses the most common high performance lookup algorithm in the kernel red: black tree to achieve hrtimer.

Before describing the implementation of Hrtimer, it is necessary to understand how to use it.

Programming interfaces and methods of Hrtimer

You need to know three APIs to use Hrtimer:

Initializes a timer object with Hrtimer_init (), sets the expiration time and expiration action with Hrtimer_start (), and adds the start timer. Remove_hrtimer () deletes a Timer.

The realization of Hrtimer

The implementation of High-precision timer and low precision timer has the following two main differences:

High-precision timers are managed by the red-black tree, not the time wheel.

The Hrtimer is independent of the system clock tick, does not use the jiffies, and uses nanoseconds as the timing unit.

All Hrtimer instances are saved in the red and black tree, and adding a timer is adding a new node to the red and black tree, and deleting the timer is the deletion of the tree node. The key value of the red-black tree is the expiration time.

Timer triggering and setting management is not performed in a regular tick interrupt, but is dynamically adjusted: After the current timer is triggered, the next interrupt trigger time for the high precision clock hardware is set to the time of the first timer in the red-black tree at the time of interrupt processing. After the clock expires, get the next Timer's expiration time from the red and black tree and set the hardware so that it loops over and over again.

Figure 1 shows the data structures used in the kernel to manage hrtimer and their relationships.

Figure 1. Data