Linux Kernel Architecture

Chapter 15: Time Management

struct hrtimer real_timer;

struct task_struct *tsk;

ktime_t it_real_incr;

/* ITIMER_PROF and ITIMER_VIRTUAL timers for the process */

cputime_t it_prof_expires, it_virt_expires;

cputime_t it_prof_incr, it_virt_incr;

...

}

Two fields are reserved for profiling and virtual timer type:

1. The time at which the next time-out is to occur (it_prof_expiresandit_virt_expires).


2. The interval after which the timer is called (it_prof_incrandit_virt_incr).

real_timeris an instance ofhrtimer(nota pointer to it) that is inserted in the other data structures of

the kernel and is used to implement real-time timers. The other two types of timer (virtual and profiling)

manage without this entry.tskpoints to the task structure of the process for which the timers are set.

The interval for real timers is specified init_real_incr.

It is therefore possible to have just three different timers ofdifferentkinds per process — given the existing

data structures, the kernel cannot manage more with thesetitimerandalarmmechanism. For example,

a process can execute a virtual and a real-time timer at the same time, but not two real-time timers.

POSIX timers that are implemented inkernel/posix-timers.cprovide an extension to this scheme

that allow more timers, but need not be discussed any further. Virtual and profiling timers are also

implemented on top of this framework.

Real-Time Timers

When installing a real-time (ITIMER_REAL) timer, it is first necessary to preserve the properties of a pos-

sibly existing old timer (they will be returned to userland once the new timer has been installed) and

cancel the timer withhrtimer_try_to_cancel. Installing a timer ‘‘overwrites‘‘ previous values.

The timer period is stored in the task-specificsignal_struct->it_real_incrfield (if this field is zero,

then the timer is not periodic, but only activated once), andhrtimer_startstarts a timer that expires at

the desired time.

No handler routine is executed in userspace when a dynamic timer expires. Instead, a signal is gener-

ated that results in the invocation of a signal handlerand thus indirectly to the invocation of a callback

function. How does the kernel ensure that the signal is sent, and how is the timer made periodic?

The kernel uses the callback handlerit_real_fn, which is executed for all userspace real-time timers.

This function sends theSIGALRMsignal to the process that installed the timer, but doesnotreinstall the

signal handler to make the signal periodic.

Instead, the timer is reinstalled when the signal is delivered in process context (indequeue_signal,

to be precise). After forwarding the expiration time withhrtimer_forward, the timer is restarted with

hrtimer_restart.

What keeps the kernel from reactivating the timer immediately after it has expired? Earlier kernel ver-

sions did, in fact, choose this approach, but problems arise if high-resolution timers are active. A process