• Understanding kernel timing

• Knowing the current time

• Delaying operation for a specified amount of time

• Scheduling asynchronous functions to happen after a specified time lapse

It is possible to change the value of HZ for those who want systems with a different clock interrupt frequency. Some people using Linux for hard real-time tasks have been known to raise the value of HZ to get better response times; they are willing to pay the overhead of the extra timer interrupts to achieve their goals. All in all, however, the best approach to the timer interrupt is to keep the default value for HZ, by virtue of our complete trust in the kernel developers, who have certainly chosen the best value.

Processor-Specific Registers

The details differ from platform to platform: the register may or may not be readable from user space, it may or may not be writable, and it may be 64 or 32 bits wide -- in the latter case you must be prepared to handle overflows. Whether or not the register can be zeroed, we strongly discourage resetting it, even when hardware permits. Since you can always measure differences using unsigned variables, you can get the work done without claiming exclusive ownership of the register by modifying its current value.

 rdtsc(low,high); rdtscl(low); 

These lines, for example, measure the execution of the instruction itself:

 unsigned long ini, end; rdtscl(ini); rdtscl(end); printk("time lapse: %li\n", end - ini); 

  #include <linux/timex.h>  cycles_t get_cycles(void); 

We'll base the example on MIPS because most MIPS processors feature a 32-bit counter as register 9 of their internal "coprocessor 0.'' To access the register, only readable from kernel space, you can define the following macro that executes a "move from coprocessor 0'' assembly instruction:[26]

  #define rdtscl(dest) \     _ _asm_ _ _ _volatile_ _("mfc0 %0,$9; nop" : "=r" (dest)) 

With this macro in place, the MIPS processor can execute the same code shown earlier for the x86.

It's quite unlikely that a driver will ever need to know the wall-clock time, since this knowledge is usually needed only by user programs such as cron and at. If such a capability is needed, it will be a particular case of device usage, and the driver can be correctly instructed by a user program, which can easily do the conversion from wall-clock time to the system clock. Dealing directly with wall-clock time in a driver is often a sign that policy is being implemented, and should thus be looked at closely.

  #include <linux/time.h>  void do_gettimeofday(struct timeval *tv); 

  void get_fast_time(struct timeval *tv); 

• The current time as returned by do_gettimeofday

• The current time as found in xtime

• The current jiffies value

We chose to use a dynamic /proc file because it requires less module code -- it's not worth creating a whole device just to return three lines of text.

If you use cat to read the file multiple times in less than a timer tick, you'll see the difference between xtime and do_gettimeofday, reflecting the fact that xtime is updated less frequently:

morgana% 
cd /proc; cat currentime currentime currentime
gettime: 846157215.937221 xtime:   846157215.931188 jiffies: 1308094 gettime: 846157215.939950 xtime:   846157215.931188 jiffies: 1308094 gettime: 846157215.942465 xtime:   846157215.941188 jiffies: 1308095  

One important thing to consider is whether the length of the needed delay is longer than one clock tick. Longer delays can make use of the system clock; shorter delays typically must be implemented with software loops.

Long Delays

   unsigned long j = jiffies + jit_delay * HZ;   while (jiffies < j)      /* nothing */; 

This kind of implementation should definitely be avoided. We show it here because on occasion you might want to run this code to understand better the internals of other code.

As you may suspect, reading /proc/jitbusy is terrible for system performance, because the computer can run other processes only once a second.

A better solution that allows other processes to run during the time interval is the following, although it can't be used in hard real-time tasks or other time-critical situations.

   while (jiffies < j)      schedule(); 

The variable j in this example and the following ones is the value of jiffies at the expiration of the delay and is always calculated as just shown for busy waiting.

If, instead, the system is very busy, the driver could end up waiting rather longer than expected. Once a process releases the processor with schedule, there are no guarantees that it will get it back anytime soon. If there is an upper bound on the acceptable delay time, calling schedule in this manner is not a safe solution to the driver's needs.

Despite its drawbacks, the previous loop can provide a quick and dirty way to monitor the workings of a driver. If a bug in your module locks the system solid, adding a small delay after each debugging printk statement ensures that every message you print before the processor hits your nasty bug reaches the system log before the system locks. Without such delays, the messages are correctly printed to the memory buffer, but the system locks before klogd can do its job.

  sleep_on_timeout(wait_queue_head_t *q, unsigned long timeout);  interruptible_sleep_on_timeout(wait_queue_head_t *q,                                 unsigned long timeout); 

Both versions will sleep on the given wait queue, but will return within the timeout period (in jiffies) in any case. They thus implement a bounded sleep that will not go on forever. Note that the timeout value represents the number of jiffies to wait, not an absolute time value. Delaying in this manner can be seen in the implementation of /proc/jitqueue:

   wait_queue_head_t wait;   init_waitqueue_head (&wait);  interruptible_sleep_on_timeout(&wait, jit_delay*HZ); 

   set_current_state(TASK_INTERRUPTIBLE);  schedule_timeout (jit_delay*HZ); 

Short Delays

 #include <linux/delay.h> void udelay(unsigned long usecs); void mdelay(unsigned long msecs); 

It's also important to remember that udelay is a busy-waiting function (and thus mdelay is too); other tasks can't be run during the time lapse. You must therefore be very careful, especially with mdelay, and avoid using it unless there's no other way to meet your goal.

Currently, support for delays longer than a few microseconds and shorter than a timer tick is very inefficient. This is not usually an issue, because delays need to be just long enough to be noticed by humans or by the hardware. One hundredth of a second is a suitable precision for human-related time intervals, while one millisecond is a long enough delay for hardware activities.

A typical situation in which you might use task queues or tasklets is to manage hardware that cannot generate interrupts but still allows blocking read. You need to poll the device, while taking care not to burden the CPU with unnecessary operations. Waking the reading process at fixed time intervals (for example, using current->timeout) isn't a suitable approach, because each poll would require two context switches (one to run the polling code in the reading process, and one to return to a process that has real work to do), and often a suitable polling mechanism can be implemented only outside of a process's context.

A similar problem is giving timely input to a simple hardware device. For example, you might need to feed steps to a stepper motor that is directly connected to the parallel port -- the motor needs to be moved by single steps on a timely basis. In this case, the controlling process talks to your device driver to dispatch a movement, but the actual movement should be performed step by step at regular intervals after returning from write.

The preferred way to perform such floating operations quickly is to register a task for later execution. The kernel supports task queues, where tasks accumulate to be "consumed'' when the queue is run. You can declare your own task queue and trigger it at will, or you can register your tasks in predefined queues, which are run (triggered) by the kernel itself.

This section first describes task queues, then introduces predefined task queues, which provide a good start for some interesting tests (and hang the computer if something goes wrong), and finally introduces how to run your own task queues. Following that, we look at the new tasklet interface, which supersedes task queues in many situations in the 2.4 kernel.

The Nature of Task Queues

A task queue is a list of tasks, each task being represented by a function pointer and an argument. When a task is run, it receives a single void * argument and returns void. The pointer argument can be used to pass along a data structure to the routine, or it can be ignored. The queue itself is a list of structures (the tasks) that are owned by the kernel module declaring and queueing them. The module is completely responsible for allocating and deallocating the structures, and static structures are commonly used for this purpose.

 struct tq_struct {     struct tq_struct *next;         /* linked list of active bh's */     int sync;                       /* must be initialized to zero */     void (*routine)(void *);        /* function to call */     void *data;                     /* argument to function */ }; 

The most important fields in the data structure just shown are routine and data. To queue a task for later execution, you need to set both these fields before queueing the structure, while next and sync should be cleared. The sync flag in the structure is used by the kernel to prevent queueing the same task more than once, because this would corrupt the next pointer. Once the task has been queued, the structure is considered "owned'' by the kernel and shouldn't be modified until the task is run.

Before getting into the details of using task queues, we need to pause for a moment to look at how they work inside the kernel.

How Task Queues Are Run

And when are task queues run? If you are using one of the predefined task queues discussed in the next section, the answer is "when the kernel gets around to it.'' Different queues are run at different times, but they are always run when the kernel has no other pressing work to do.

A number of actions require the context of a process in order to be executed. When you are outside of process context (i.e., in interrupt mode), you must observe the following rules:

• No access to user space is allowed. Because there is no process context, there is no path to the user space associated with any particular process.

• The current pointer is not valid in interrupt mode, and cannot be used.

• No sleeping or scheduling may be performed. Interrupt-mode code may not call schedule or sleep_on; it also may not call any other function that may sleep. For example, calling kmalloc(..., GFP_KERNEL) is against the rules. Semaphores also may not be used since they can sleep.

Although rescheduling the same task over and over might appear to be a pointless operation, it is sometimes useful. For example, consider a driver that moves a pair of stepper motors one step at a time by rescheduling itself on the timer queue until the target has been reached. Another example is the jiq module, where the printing function reschedules itself to produce its output -- the result is several iterations through the timer queue.

Predefined Task Queues

Other predefined task queues exist as well, but they are not generally of interest to driver writers.

How the examples work

  DECLARE_WAIT_QUEUE_HEAD (jiq_wait); 

The buffer is filled by successive runs of a task queue. Each pass through the queue appends a text string to the buffer being filled; each string reports the current time (in jiffies), the process that is current during this pass, and the return value of in_interrupt.

  struct tq_struct jiq_task; /* global: initialized to zero */      /* these lines are in jiq_init() */     jiq_task.routine = jiq_print_tq;     jiq_task.data = (void *)&jiq_data; 

There's no need to clear the sync and next fields of jiq_task because static variables are initialized to 0 by the compiler.

The scheduler queue

  int schedule_task(struct tq_struct *task); 

task, of course, is the task to be scheduled. The return value is directly from queue_task: nonzero if the task was not already on the queue.

There are a couple of implications to the keventd implementation that are worth keeping in mind. The first is that tasks in this queue can sleep, and some kernel code takes advantage of that freedom. Well-behaved code, however, should take care to sleep only for very short periods of time, since no other tasks will be run from the scheduler queue while keventd is sleeping. It is also a good idea to keep in mind that your task shares the scheduler queue with others, which can also sleep. In normal situations, tasks placed in the scheduler queue will run very quickly (perhaps even before schedule_task returns). If some other task sleeps, though, the time that elapses before your tasks execute could be significant. Tasks that absolutely have to run within a narrow time window should use one of the other queues.

/proc/jiqsched is a sample file that uses the scheduler queue. The read function for the file dispatches everything to the task queue in the following way:

  int jiq_read_sched(char *buf, char **start, off_t offset,                    int len, int *eof, void *data) {      jiq_data.len = 0;               /* nothing printed, yet */     jiq_data.buf = buf;             /* print in this place */     jiq_data.jiffies = jiffies;     /* initial time */      /* jiq_print will queue_task() again in jiq_data.queue */     jiq_data.queue = SCHEDULER_QUEUE;      schedule_task(&jiq_task);             /* ready to run */     interruptible_sleep_on(&jiq_wait);    /* sleep till completion */      *eof = 1;     return jiq_data.len; } 

Reading /proc/jiqsched produces output like the following:

  time  delta interrupt  pid cpu command 601687   0        0       2   1 keventd 601687   0        0       2   1 keventd 601687   0        0       2   1 keventd 601687   0        0       2   1 keventd 601687   0        0       2   1 keventd 601687   0        0       2   1 keventd 601687   0        0       2   1 keventd 601687   0        0       2   1 keventd 601687   0        0       2   1 keventd 

In this output, the time field is the value of jiffies when the task is run, delta is the change in jiffies since the last time the task ran, interrupt is the output of the in_interrupt function, pid is the ID of the running process, cpu is the number of the CPU being used (always 0 on uniprocessor systems), and command is the command being run by the current process.

The timer queue

The sample code implements /proc/jiqtimerwith the timer queue. For this queue, it must use queue_task to get things going:

  int jiq_read_timer(char *buf, char **start, off_t offset,                    int len, int *eof, void *data) {      jiq_data.len = 0;            /* nothing printed, yet */     jiq_data.buf = buf;          /* print in this place */     jiq_data.jiffies = jiffies;  /* initial time */     jiq_data.queue = &tq_timer;  /* reregister yourself here */      queue_task(&jiq_task, &tq_timer);     /* ready to run */     interruptible_sleep_on(&jiq_wait);    /* sleep till completion */      *eof = 1;     return jiq_data.len; } 

The following is what head /proc/jiqtimerreturned on a system that was compiling a new kernel:

     time  delta interrupt  pid cpu command  45084845   1        1    8783   0 cc1  45084846   1        1    8783   0 cc1  45084847   1        1    8783   0 cc1  45084848   1        1    8783   0 cc1  45084849   1        1    8784   0 as  45084850   1        1    8758   1 cc1  45084851   1        1    8789   0 cpp  45084852   1        1    8758   1 cc1  45084853   1        1    8758   1 cc1  45084854   1        1    8758   1 cc1  45084855   1        1    8758   1 cc1 

Note, this time, that exactly one timer tick goes by between each invocation of the task, and that an arbitrary process is running.

The immediate queue

The immediate queue is the fastest queue in the system -- it's executed soonest and is run in interrupt time. The queue is consumed either by the scheduler or as soon as one process returns from its system call. Typical output can look like this:

     time  delta interrupt  pid cpu command  45129449   0        1    8883   0 head  45129453   4        1       0   0 swapper  45129453   0        1     601   0 X  45129453   0        1     601   0 X  45129453   0        1     601   0 X  45129453   0        1     601   0 X  45129454   1        1       0   0 swapper  45129454   0        1     601   0 X  45129454   0        1     601   0 X  45129454   0        1     601   0 X  45129454   0        1     601   0 X  45129454   0        1     601   0 X  45129454   0        1     601   0 X  45129454   0        1     601   0 X 

It's clear that the queue can't be used to delay the execution of a task -- it's an "immediate'' queue. Instead, its purpose is to execute a task as soon as possible, but at a safe time. This feature makes it a great resource for interrupt handlers, because it offers them an entry point for executing program code outside of the actual interrupt management routine. The mechanism used to receive network packets, for example, is based on a similar mechanism.

Running Your Own Task Queues

Unlike a predefined task queue, however, a custom queue is not automatically run by the kernel. The programmer who maintains a queue must arrange for a way of running it.

  DECLARE_TASK_QUEUE(tq_custom); 

   queue_task(&custom_task, &tq_custom); 

  run_task_queue(&tq_custom); 

If you want to experiment with custom queues now, you need to register a function to trigger the queue in one of the predefined queues. Although this may look like a roundabout way to do things, it isn't. A custom queue can be useful whenever you need to accumulate jobs and execute them all at the same time, even if you use another queue to select that "same time.''

Tasklets

Tasklets resemble task queues in a number of ways. They are a way of deferring a task until a safe time, and they are always run in interrupt time. Like task queues, tasklets will be run only once, even if scheduled multiple times, but tasklets may be run in parallel with other (different) tasklets on SMP systems. On SMP systems, tasklets are also guaranteed to run on the CPU that first schedules them, which provides better cache behavior and thus better performance.

Each tasklet has associated with it a function that is called when the tasklet is to be executed. The life of some kernel developer was made easier by giving that function a single argument of type unsigned long, which makes life a little more annoying for those who would rather pass it a pointer; casting the long argument to a pointer type is a safe practice on all supported architectures and pretty common in memory management (as discussed in Chapter 13, "mmap and DMA"). The tasklet function is of type void; it returns no value.

The sample jiq driver, when compiled against 2.4 headers, implements /proc/jiqtasklet, which works like the other jiq entries but uses tasklets; we didn't emulate tasklets for older kernel versions in sysdep.h. The module declares its tasklet as

  void jiq_print_tasklet (unsigned long); DECLARE_TASKLET (jiq_tasklet, jiq_print_tasklet, (unsigned long)     &jiq_data); 

   tasklet_schedule(&jiq_tasklet); 

Once a tasklet is scheduled, it is guaranteed to be run once (if enabled) at a safe time. Tasklets may reschedule themselves in much the same manner as task queues. A tasklet need not worry about running against itself on a multiprocessor system, since the kernel takes steps to ensure that any given tasklet is only running in one place. If your driver implements multiple tasklets, however, it should be prepared for the possibility that more than one of them could run simultaneously. In that case, spinlocks must be used to protect critical sections of the code (semaphores, which can sleep, may not be used in tasklets since they run in interrupt time).

The output from /proc/jiqtasklet looks like this:

     time  delta interrupt  pid cpu command  45472377   0        1    8904   0 head  45472378   1        1       0   0 swapper  45472379   1        1       0   0 swapper  45472380   1        1       0   0 swapper  45472383   3        1       0   0 swapper  45472383   0        1     601   0 X  45472383   0        1     601   0 X  45472383   0        1     601   0 X  45472383   0        1     601   0 X  45472389   6        1       0   0 swapper 

Note that the tasklet always runs on the same CPU, even though this output was produced on a dual-CPU system.

The tasklet subsystem provides a few other functions for advanced use of tasklets:

There are times when you need to execute operations detached from any process's context, like turning off the floppy motor or finishing another lengthy shutdown operation. In that case, delaying the return from close wouldn't be fair to the application program. Using a task queue would be wasteful, because a queued task must continually reregister itself until the requisite time has passed.

A timer is much easier to use. You register your function once, and the kernel calls it once when the timer expires. Such a functionality is used often within the kernel proper, but it is sometimes needed by the drivers as well, as in the example of the floppy motor.

  struct timer_list {      struct timer_list *next;          /* never touch this */      struct timer_list *prev;          /* never touch this */      unsigned long expires;            /* the timeout, in jiffies */      unsigned long data;               /* argument to the handler */      void (*function)(unsigned long);  /* handler of the timeout */      volatile int running;             /* added in 2.4; don't touch */  }; 

These are the functions used to act on timers:

The code for /proc/jitimer is as follows:

  struct timer_list jiq_timer;  void jiq_timedout(unsigned long ptr) {     jiq_print((void *)ptr);            /* print a line */     wake_up_interruptible(&jiq_wait);  /* awaken the process */ }   int jiq_read_run_timer(char *buf, char **start, off_t offset,                    int len, int *eof, void *data) {      jiq_data.len = 0;      /* prepare the argument for jiq_print() */     jiq_data.buf = buf;     jiq_data.jiffies = jiffies;     jiq_data.queue = NULL;      /* don't requeue */      init_timer(&jiq_timer);              /* init the timer structure */     jiq_timer.function = jiq_timedout;     jiq_timer.data = (unsigned long)&jiq_data;     jiq_timer.expires = jiffies + HZ; /* one second */      jiq_print(&jiq_data);   /* print and go to sleep */     add_timer(&jiq_timer);     interruptible_sleep_on(&jiq_wait);     del_timer_sync(&jiq_timer);  /* in case a signal woke us up */          *eof = 1;     return jiq_data.len; } 

Running head /proc/jitimer gives the following output:

     time  delta interrupt  pid cpu command  45584582   0        0    8920   0 head  45584682 100        1       0   1 swapper 

From the output you can see that the timer function, which printed the last line here, was running in interrupt mode.

What can appear strange when using timers is that the timer expires at just the right time, even if the processor is executing in a system call. We suggested earlier that when a process is running in kernel space, it won't be scheduled away; the clock tick, however, is special, and it does all of its tasks independent of the current process. You can try to look at what happens when you read /proc/jitbusy in the background and /proc/jitimer in the foreground. Although the system appears to be locked solid by the busy-waiting system call, both the timer queue and the kernel timers continue running.

  interruptible_sleep_on_timeout(my_queue, timeout); 

used to be implemented as

 current->timeout = jiffies + timeout; interruptible_sleep_on(my_queue); 

The sysdep.h header recreates schedule_timeout for pre-2.4 kernels so that you can use the new syntax and run on 2.0 and 2.2:

  extern inline void schedule_timeout(int timeout) {     current->timeout = jiffies + timeout;     current->state = TASK_INTERRUPTIBLE;     schedule();     current->timeout = 0; } 

  extern inline int schedule_task(struct tq_struct *task) {         queue_task(task, &tq_scheduler);         return 1; } 

As has been mentioned, the 2.3 development series added the tasklet mechanism; before, only task queues were available for "immediate deferred'' execution. The bottom-half subsystem was implemented differently, though most of the changes are not visible to driver writers. We didn't emulate tasklets for older kernels in sysdep.h because they are not strictly needed for driver operation; if you want to be backward compatible you'll need to either write your own emulation or use task queues instead.