Delay and timing

Delay Operation:

Long delay, longer than a tick of time.

Busy waiting:

By monitoring the Jiffies register implementation

while (Time_before (JIFFIES,J1))

Cpu_relax ();

The implementation of Cpu_relax () is related to the platform, and most departments do not do anything at all, and on symmetric multithreaded systems, the processor may be ceded to other threads.

If interrupts are disabled before entering the loop, then the jiffies value is not updated and the while is always true. It can only be restarted.

Active surrender of the processor:

Give up the processor when the processor is not needed, but still running the queue

Call the Schedule function implementation

while (Time_before (JIFFIES,J1))

Schedule ();

If the system is busy, it will be delayed for a long time.

Timeout:

Sleep, etc timeout time to wake up

#include <linux/wait.h>

Longwait_event_timeout (wait_queue_head_t Q, condition, long timeout);

Longwait_event_interruptible_timeout (wait_queue_head_t Q, condition, longtimeout);

Timeout represents the Jiffies value to wait for, not an absolute time value, which is represented by a signed number, which is generally the result of subtracting, and when the supplied timeout value is negative, a one-day complaint message is generated through PRINTK. If the timeout expires, 0 is returned. If there are other events waking up, the remaining deferred implementations are generated, and the return value is never negative, even if the actual latency exceeds expectations due to system load.

If you are not waiting for a specific event to delay, you can use the Schedule_timeout function to avoid declaring and using redundant wait queue headers

#include <linux/sched.h>

Signedlong Schedule_timeout (signed long timeout);

Schedule_timeout requires the user to first set the current process state:

Set_current_state (task_interruptible);

Schedule_timeout (delay);

Short delay:

When dealing with hardware delays, it typically involves a maximum of dozens of milliseconds

The following functions delay the specified number of nanoseconds, microseconds, and milliseconds, respectively:

#include <linux/delay.h>

Voidndelay (unsigned long nsecs);

Voidudelay (unsigned long usecs);

Voidmdelay (unsigned long msecs);

These functions are actually included in the <asm/delay.h>

All schemas will implement Udelay, but other functions may not be defined.

The implementation of Udelay uses software loops, which determine the number of cycles based on the processor speed computed during boot and the loops_pre_jiffy integer variable. To avoid integer overflows in circular computations, udelay and Ndelay impose an upper limit on the values passed to them, and if the module fails to load and displays unresolved symbol __bad_udelay, then the value passed too large when the udelay is called.

The above is busy waiting, also has the use of sleep

#include <linux/delay.h>

Voidmsleep (unsigned int millisecs);

Unsignedlong msleep_interruptible (unsigned int millisecs);

Voidssleep (unsigned int seconds);

Ssleep non-interruptible sleep seconds, msleep_interruptible can be interrupted.

Kernel timers:

A kernel timer is a data structure that tells the kernel to execute a user-defined function with user-defined parameters at a user-defined point in time. Its implementation is located in <linux/timer.h> and <kernel/timer.c> files.

This call is executed asynchronously, when the timer runs, the process that dispatched the timer may be hibernating or executed on another processor, or simply exited.

This asynchronous execution is similar to a scenario when a hardware interrupt occurs. The timer function must be executed atomically, and this non-process context also brings other problems:

Access to user space is not allowed because the non-process context does not have user space

The current pointer has no meaning in atomic mode and is not available because there is no correlation between the code and the interrupted process

Hibernation and scheduling cannot be performed. Atomic code cannot call schedule or wait_event, nor can it invoke any function that might cause hibernation.

The kernel code can determine whether it is running in the interrupt context by calling the function In_interrupt (), which does not require parameters, and if the processor is running in the interrupt context, returns a value other than 0, whether it is a hardware interrupt or a software outage. Associated with In_interrupt is in_atomic (), whose return value is also a non-0 value when scheduling is not allowed, including hardware and software interrupt contexts and any point in time when a spin lock is not allowed. In the latter case, current is available, but it is forbidden to access the user space, because this causes the schedule to occur, and whenever you use In_interrupt (), you should consider whether you should really use In_atomic (). Both of these functions are declared in <asm/hardirq.h>.

Timer API:

The kernel provides a set of functions for the driver to declare, register, and delete kernel timers:

#include <linux/timer.h>

structtimer_lsit{

...

Unsignedlong Expirse;

void (*function) (unsigned long);

Unsignedlong data;

};

Voidinit_timer (struct time_list *timer);

Structtimer_list Timer_initializer (_function, _expires, _data);

Voidadd_timer (struct timer_list *timer);

Voiddel_timer (struct timer_list *timer);

The Expiress field indicates that the expected timer executes the jiffies value, does not use jiffies_64, and then calls the function, data as the parameter.

initialization, runtime initialization, or assigning Timer_initializer to a static structure. After initialization, you can modify the above three public fields before calling Add_timer, and these three fields can be accessed by code other than the timer.

Other Timer APIs:

Intmod_timer (struct timer_list *timer, unsigned long expires);

Update a timer expiry time, often used for time-out timers (such as the motor shutdown time of the floppy drive)

Intdel_time_sync (struct timer_list *timer);

Similar to Del_timer work, but you can ensure that no CPU is running when the timer function is returned. Generally used to avoid the race on the SMP, if the timer function will re-register itself, you must ensure that no re-registration occurs, which is usually set by the timer function check the "OFF" flag to achieve.

inttimer_pending (const struct timer_list *timer);

By reading the timer_list structure a non-visible field returns whether the timer is being scheduled to run.

Implementation of the kernel timer:

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

The management of timers must be as lightweight as possible

The design must be very flexible when the active timer increases greatly.

Most timers expire in up to a few seconds or minutes, with few timers with long delays

The timer should run on the unified CPU that registers it

The solution used by kernel developers is to take advantage of the PER-CPU data structure, where the base field of the timer_list structure contains pointers to that structure. If base is null, the timer has not been scheduled to run, otherwise the pointer will tell us which data structure it is.

The concrete realization has the reference value

This article is from the "No Front" blog, please be sure to keep this source http://qianyang.blog.51cto.com/7130735/1620579

Delay and timing