A closer look at Linux kernel timers: interrupt-based asynchronous mechanisms and non-process context principles

1. Kernel timer 1. Basic concepts

In certain scenarios, we need to perform certain actions after a specific time, and we don’t want to waste CPU by waiting. At this time, the timer is a very suitable mechanism. A timer is used to execute a function at a certain point in the future to complete a specific task.

Kernel timers tell the kernel to call a specific function with specific parameters at a specified point in time. The timer runs asynchronously on its registrant. When the timer is running, the task that registered the timer may be sleeping or running on other processors, or may even have exited long ago.

The kernel timer in Linux is implemented based on (soft) interrupts Linux application timer, that is, it is in the interrupt context rather than the process context. There are some principles to follow in non-process context:

Access to user space is not allowed

current is meaningless and therefore unavailable

Cannot sleep or schedule. Schedule or some kind of wait_event cannot be called, nor can any function that may cause sleep be called. Semaphores are also not available since semaphores may cause hibernation.

The kernel code can determine whether it is currently in the interrupt context by calling the function in_interrupt(). As long as it returns non-0, it means it is in the interrupt context. The kernel can determine whether scheduling is currently allowed by calling in_atomic(). Situations where scheduling is not allowed include: being in an interrupt context and a context that owns a carrier lock.

Because the timer is executed asynchronously, the timer processing function must pay attention to mutual exclusion protection.

2.Timers supported by linux kernel

The Linux kernel supports two types of timers:

Classic timer: a timer whose accuracy depends on the frequency of computer clock interrupts. The timer accuracy is usually relatively low, with an accuracy of 1000/HZms. This timer is generated at a fixed frequency, that is, every 1000/HZms. If the dynamic clock feature is not enabled, no real timing disturbance may occur when the timer expires. For example, only the following timers are added to the system: 11ms, 52ms, and 78ms expiration timers, and the timers expire accurately. The typical timer will expire at multiples of 4 ms (4, 8, 12...), so there may not necessarily be a timing disturbance at the time when the timer expires.

High frame rate timer: The precision of the classic timer is relatively low. In some situations, a higher precision timer is required, such as multimedia applications in the Chinese Linux operating system, so this type of timer is introduced in the system. This timer can essentially occur at any time.

Two concepts of exception are also needed here:

Dynamic clock: The periodic clock linux application timer is only activated when a task needs to be actually executed, otherwise the periodic clock technology is disabled. The approach is to disable the periodic clock if you need to schedule idle to run; then enable the periodic clock until the next timer expires or an interrupt occurs. One-shot clock is a prerequisite for realizing dynamic clock, because the key feature of dynamic clock is that the clock can be stopped or restarted as needed, and pure periodic clock is not suitable for these scenarios.

Periodic clock: A clock that forms clock time periodically.

In terms of application, timers have two main uses:

Timeout: Indicates a disturbance that will occur after a certain period of time. In fact, when using timeout, in most cases, the timeout is not expected to occur, and the timer is often canceled before timeout. In addition, although it is not canceled, the timeout incident is often not an accurate incident. For example, the various timeout timers used in the network often express the meaning that if there is no... before this point in time, it can be considered ..., the value of this time is often an empirical value or a calculated value, and is not a precise time requirement. In these situations the classic timer is sufficient.

Timer: used to implement timing. For example, when playing sound, data needs to be sent to the sound card regularly. In these situations, there are strict requirements on time. If data is not sent to the sound card at a certain point in time, sound distortion will occur. . At this time, a high-precision timer must be used.

Linux can be prompted to work in the following mode through configuration:

High frame rate dynamic clock

High frame rate period clock

Low bitrate dynamic clock

Low code rate period clock

3. Low bitrate kernel timer

The low-bitrate timer is the most common kernel timer. The kernel will use the processor's clock interrupt or any other appropriate periodic clock source as the time baseline of the timer. Clock interrupts occur periodically, HZ times per second. The timer processing function corresponding to this interrupt is usually timer_interrupt. In the processing of this function, it will eventually be adjusted to do_timer and update_process_timers. Among them, do_timer will be responsible for system-wide and global tasks: updating jiffies and processing process statistics; and the latter function will perform process statistics to form TIMER_SOFTIRQ to provide time awareness to the scheduler.

When the timer expires, the timer will be removed from the activation array before the timer processing function is called. Therefore, if you want to re-execute after a period of time after this execution, you need to re-add the timer. device. In the SMP system, the timer function will be executed by the CPU where it is registered.

The implementation of the kernel timer must meet the following requirements and assumptions:

Timer management must be as simple as possible.

The design must have good scalability when the activity timer is greatly reduced

Most timers expire within a few seconds or at most a few minutes, and timers with long delays are quite rare.

A timer should run on the same CPU as where it was registered.

The implementation of the low bit rate kernel timer is very clever. It is based on a per-CPU data structure. The base array of timer_list contains pointers pointing to this structure. If base is NULL, this timer has not been called to run; otherwise, this pointer tells which data structure (that is, which CPU) is running it.

Whenever kernel code registers a timer (via add_timer or mod_timer), the operation is ultimately performed by internal_add_timer (in kernel/timer.c), which adds the new timer to the "cascade table" associated with the current CPU "in the timer one-way array.

How cascading tables work:

If the timer expires within the next 0 to 255 jiffies, it is added to one of the 256 arrays specially provided for short-term timers, using expires (that is, which array is added to is determined by the expiration time bits) The lower 8 bits of the determined) determine which array to add to

If it expires further in the future (but before 16384 jiffies), it is added to one of the 64 arrays. These 64 arrays are related to the 8-13 bits of expires. The 6 of expires The bits determine which array is used.

Similar techniques are applied to expires bits 14-19, 20-25 and 26-31.

If the timer expires at a later date

The above is the detailed content of A closer look at Linux kernel timers: interrupt-based asynchronous mechanisms and non-process context principles. For more information, please follow other related articles on the PHP Chinese website!