struct tick_sched {

struct hrtimer sched_timer;

The function tick_sched_timer is used as the callback handler. To avoid a situation in which all CPUs are engaged in running the periodic tick handlers at the same time, the kernel distributes the acceleration time as shown in Figure 15-16. Recall that the length of a tick period (in nanoseconds) is tick_period. The ticks are spread across the first half of this period. Assume that the first tick starts at time 0. If the system contains N CPUs, the remaining periodic ticks are started at times A, 2A, 3 A, ... The offset A is given by tick_period/(2N).

I periodic tick occurs


0 tick_period/2 tick_period time

Figure 15-16: Distributing periodic tick handlers in high-resolution mode.

The tick timer is registered like every other regular high-resolution timer. The function displays some similarities to tick_periodic, but is slightly more complicated. The code flow diagram is shown in Figure 15-17.

If the CPU that is currently executing the timer is responsible to provide the global tick (recall that this duty has already been distributed in low-resolution mode at boot time), then tick_do_update_jiffies64 computes the number of jiffies that have passed since the last update — in our case, this will always be

1 because I do not consider dynamic tick mode for now. The previously discussed function do_timer is used to handle all duties of the global timer. Recall that this includes updating the global jiffies64 variable.

Figure 15-17: Code flow diagram for tick_sched_timer.

When the per-CPU periodic tick tasks have been performed in update_process_times (see Section 15.8) and profile_tick, the time for the next event is computed, and hrtimer_forward programs the timer accordingly. By returning HRTIMER_RESTART, the timer is automatically re-queued and activated when the next tick is due.

Continue reading here: Switching to High Resolution Timers

Was this article helpful?

0 0