Linux kernel device driver kernel time management notes

/******************
 * Linux kernel time management *********************/

(1) Concept of time in the kernel

Time management plays a very important role in the Linux kernel.

Compared with event-driven, there are a large number of functions in the kernel that are time-driven.

Some functions are executed periodically, such as refreshing the screen every 10 milliseconds;

Some functions are executed after a certain period of time, such as the kernel executing a task after 500 milliseconds.

To distinguish:

• *Absolute time and relative time
• * Periodically generated events and deferred events

Periodic events are driven by the system timer

(2)HZ value

The kernel must have the help of hardware timers to calculate and manage time.

The frequency at which a timer generates interrupts is called its tick rate.

A variable HZ is specified in the kernel, and the timer beat rate is determined based on this value when the kernel is initialized.

HZ is defined in <asm/param.h>. On the i386 platform, the current HZ value used is 1000.

That is, the clock interrupt occurs 1000 times per second, with a period of 1 millisecond. Right now:

#define HZ 1000

Notice! HZ is not a fixed value, it can be changed and can be entered when the kernel source code is configured.

Different architectures have different HZ values, for example, arm uses 100.

If you want to use the system interrupt frequency in the driver, use HZ directly instead of 100 or 1000

a. Ideal HZ value

The HZ value of i386 has always been 100, until it was changed to 1000 after version 2.5.

Increasing the tick rate means that clock interrupts are generated more frequently and interrupt handlers are executed more frequently.

The benefits are:

• * Kernel timers can run at higher frequencies and with higher accuracy
• * System calls that rely on timers, such as poll() and select(), run with higher precision
• * Improve the accuracy of process preemption

(Shortened scheduling delay, if the process has 2ms time slice left, in a 10ms scheduling cycle, the process will run 8ms longer.
Due to the delay in preemption, some time-critical tasks will be affected)

The disadvantages are:

*The higher the beat rate, the heavier the system burden.

Interrupt handlers will take up more processor time.

(3) jiffies

The global variable jiffies is used to record the total number of beats generated since the system was started.

At startup, jiffies is initialized to 0 and incremented by the clock interrupt handler each time thereafter.

In this way, the running time after the system is started is jiffies/HZ seconds

Jiffies are defined in <linux/jiffies.h>:

extern unsigned long volatile jiffies;

The jiffies variable is always of type unsigned long.

So on 32-bit architecture it is 32-bit, and on 64-bit architecture it is 64-bit. For 32-bit jiffies, if HZ is 1000, it will overflow after 49.7 days. Although overflow is uncommon, it is still possible for a program to cause errors due to wrapping when detecting a timeout. Linux provides four macros to compare beat counts, which can correctly handle beat count wraparound.

#include <linux/jiffies.h>
#define time_after(unknown, known) // unknow > known
#define time_before(unknown, known) // unknow < known
#define time_after_eq(unknown, known) // unknow >= known
#define time_before_eq(unknown, known) // unknow <= known

Unknown usually refers to jiffies, and known is the value to be compared (usually a relative value calculated by adding or subtracting jiffies). For example:

unsigned long timeout = jiffies + HZ/2; /* timeout after 0.5 seconds */
...
if (time_before(jiffies, timeout)) {
/* No timeout, good */
}else{
/* Timeout, error occurred */

time_before can be understood as if it is completed before the timeout (before)

*A 64-bit value jiffies_64 is also declared in the system. In a 64-bit system, jiffies_64 and jiffies are the same value.

This value can be obtained through get_jiffies_64().

*use

u64 j2;
j2 = get_jiffies_64();

(4) Get the current time

Drivers generally do not need to know the wall clock time (that is, the time of the year, month, and day). But the driver may need to deal with absolute times.
For this purpose, the kernel provides two structures, both defined in <linux/time.h>:

struct timeval {
 time_t tv_sec; /* seconds */
 suseconds_t tv_usec; ​​/* microseconds */
};
// Older, but popular. Using seconds and milliseconds, it stores the number of seconds since 0:00 on January 1, 1970. struct timespec {
 time_t tv_sec; /* seconds */
 long tv_nsec; /* nanoseconds */
};
// Newer, uses seconds and nanoseconds to save time.

do_gettimeofday() This function fills a pointer variable pointing to struct timeval with the usual seconds or microseconds. The prototype is as follows:

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

current_kernel_time() This function can be used to obtain timespec

#include <linux/time.h>
struct timespec current_kernel_time(void);

/********************
 *Delayed execution of determined time********************/

Device drivers often need to delay the execution of certain code for a period of time, usually to allow the hardware to complete some task.

Delays longer than the timer period (also called a clock tick) can be accomplished by using the system clock, while very short delays can be accomplished by means of software loops.

(1) Short delay

For delays of up to a few tens of milliseconds, there is no way to use the system timer.

The system provides the following delay functions through software loops:

#include <linux/delay.h> 
/* Actually in <asm/delay.h> */
void ndelay(unsigned long nsecs); /*delay nanoseconds*/
void udelay(unsigned long usecs); /*delay in microseconds*/
void mdelay(unsigned long msecs); /*delay in milliseconds*/

These three delay functions are all busy waiting functions, and other tasks cannot be run during the delay process.

In fact, nanosecond precision is not currently possible on all platforms.

(2) Long delay

a. Give up the processor before the delay expires

while(time_before(jiffies, j1))
schedule();

The processor can be released during the waiting period, but the system cannot enter idle mode (because this process is always being scheduled), which is not conducive to power saving.

b. Timeout function

#include <linux/sched.h>
signed long schedule_timeout(signed long timeout);

Directions:

set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(2*HZ); /* sleep for 2 seconds*/

The process will be woken up after 2 seconds. If you do not want to be interrupted by user space, you can set the process state to TASK_UNINTERRUPTIBLE.

msleep
ssleep // seconds

(3) Waiting queue

Long delays can also be achieved using wait queues.

During the delay, the current process sleeps in the wait queue.

When a process is sleeping, it needs to be linked to a waiting queue based on the event it is waiting for.

a. Declare the waiting queue

The waiting queue is actually a process linked list, which contains all processes waiting for a specific event.

#include <linux/wait.h>
struct __wait_queue_head {
    spinlock_t lock;
    struct list_head task_list;
};
typedef struct __wait_queue_head wait_queue_head_t;

To add a process to the waiting queue, the driver must first declare a waiting queue head in the module and initialize it.

Static Initialization

DECLARE_WAIT_QUEUE_HEAD(name);

Dynamic Initialization

wait_queue_head_t my_queue;
init_waitqueue_head(&my_queue);

b. Waiting function

A process can sleep for a fixed time in a waiting queue by calling the following function:

#include <linux/wait.h>
long wait_event_timeout(wait_queue_head_t q,condition, long timeout);
long wait_event_interruptible_timeout(wait_queue_head_t q, condition, long timeout);

After calling these two functions, the process will sleep on the given wait queue q, but will return when the timeout expires.

If the timeout expires, it returns 0, if the process is woken up by some other event, it returns the amount of time remaining.

If there is no waiting condition, set condition to 0

Directions:

wait_queue_head_t wait;
init_waitqueue_head(&wait);
wait_event_interruptible_timeout(wait, 0, 2*HZ); 
/*The current process sleeps for 2 seconds in the waiting queue */

(4) Kernel Timer

Another way to delay the execution of a task is to use a kernel timer. Unlike the previous delay methods, the kernel timer does not block the current process. Starting a kernel timer only declares that a task will be executed at some point in the future, and the current process continues to execute. Don't use timers for hard real-time tasks

The timer is represented by the structure timer_list, which is defined in <linux/timer.h>

struct timer_list{
struct list_head entry; /* Timer linked list */
unsigned long expires; /* Timing value in jiffies*/
spinlock_t lock;
void(*function)(unsigned long); /* Timer processing function*/
unsigned long data; /* Parameters passed to the timer processing function*/
}

The kernel provides a series of interfaces for managing timers in <linux/timer.h>.

a. Create a timer

struct timer_list my_timer;

b. Initialize the timer

init_timer(&my_timer);
/* Fill the data structure */
my_timer.expires = jiffies + delay;
my_timer.data = 0;
my_timer.function = my_function; /*Function called when the timer expires*/

c. Timer execution function

The prototype of the timeout processing function is as follows:

void my_timer_function(unsigned long data);

You can use the data parameter to handle multiple timers with one processing function. You can set data to 0

d. Activate the timer

add_timer(&my_timer);

The timer starts running once it is activated.

e. Change the timeout period of an activated timer

mod_timer(&my_timer,
    jiffies+ney_delay);

It can be used for timers that have been initialized but not yet activated. If the timer is not activated when called, it returns 0, otherwise it returns 1. Once mod_timer returns, the timer will be activated.

f. Delete timer

del_timer(&my_timer);

Either activated or inactivated timers can be used. If the timer is inactivated when called, it returns 0, otherwise it returns 1. No need to call for timers that have timed out, they are automatically deleted

g. Synchronous deletion

del_time_sync(&my_timer);

In smp systems, ensure that all timer handlers exit on return. Cannot be used in interrupt context.

/********************
 *Delayed execution of uncertain time********************/

(1) What is an indeterminate delay?

The previous section introduces the delayed execution of a certain time, but this situation is often encountered in the process of writing drivers: the user space program calls the read function to read data from the device, but no data is currently generated in the device. At this point, the default operation of the driver's read function is to go into sleep mode and wait until there is data in the device.

This kind of waiting is an indefinite delay, which is usually achieved by using a sleep mechanism.

(2) Sleep

Sleeping is based on waiting queues. We have introduced the wait_event series of functions before, but now we will not have a fixed sleep time.

When a process is put to sleep, it is marked with a special state and removed from the scheduler's run queue.

Until certain events occur, such as the device receiving data, the process is reset to the running state and enters the running queue for scheduling.

The header file of the sleep function is <linux/wait.h>, and the specific implementation function is in kernel/wait.c.

a. Rules of dormancy

• * Never sleep in an atomic context
• * When we are awakened, we have no idea how much time we have slept, or whether we have the resources we need after waking up
• * A process cannot sleep unless it knows that another process will wake it up somewhere else

b. Initialization of waiting queue

See previous article

c. Sleep function

The simplest sleep mode in Linux is the wait_event macro. This macro checks the condition that the process is waiting for while implementing sleep.

1. void wait_event(
   wait_queue_head_t q, 
   int condition);

2. int wait_event_interruptible(
   wait_queue_head_t q, 
   int condition);

• q: is the head of the waiting queue. Note that it is passed by value.
• condition: Any Boolean expression. The process will remain dormant until the condition is true.
• Notice! The process can only be awakened through the wake-up function, and the conditions need to be detected at this time.
• If the condition is met, the awakened process actually wakes up;
• If the condition is not met, the process continues to sleep.

d. Wake-up function

When our process goes to sleep, it needs to be awakened by some other execution thread (which may be another process or an interrupt handling routine). Wake-up function:

#include <linux/wait.h>
1. void wake_up(
  wait_queue_head_t *queue);

2. void wake_up_interruptible(
  wait_queue_head_t *queue);

wake_up will wake up all processes waiting on the given queue. And wake_up_interruptible wakes up processes that are performing interruptible sleep. In practice, the convention is to use wake_up when using wait_event, and to use wake_up_interruptible when using wait_event_interruptible.

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM. If you want to learn more about this, please check out the following links