LINUX kernel process scheduling strategy
A: scheduling occasions:
Kernel: Process own call schedule () or schedule_timeout () through the system voluntarily give up the CPU, CPU scheduling so that other processes. (Schedule_timeout () can be specified to give up CPU time)
1: Voluntary schedule:
User space: the process through the system call pause () or nanosleep () voluntarily give up CPU. (Nanosleep () can also be specified to give up CPU time. In addition, Sleep (), Sleep_on () library function is not a system call, ultimately achieved by giving up CPU system calls)
2: Involuntary schedule:
Mainly occurs when the system returns from kernel mode to user mode (i.e., the system returns from space to user space),
Mainly in the following situations: when the user process makes a system call returns (system call in the system space completed); interrupt processing is completed (interrupt handling system is in space); exception handling is completed (also exception handling system space) .
When the CPU system each time you return from space to user space, will conduct a process scheduling. In addition, each time a clock interrupt occurs, find the current running process time slice expires, will conduct a process scheduling (which is also LINUX system, each process can get performance reasons, otherwise, if a process does not make a system call, there are no abnormal operation itself, not voluntarily give up the CPU, system and without interruption, the process will wait until the time slice is used up). In other words, the process of scheduling mandatory only occur in user space, will never occur in the system space.
II: scheduling: "conditional preemptive" approach. By scheduling the timing of the above analysis, we can see, LINUX kernel process scheduling is "conditional preemptive" approach, when the system is running in the system space, has not been denied, but once the system is returned from the system returns to space when the user space, the current process is likely to be deprived of the right to occupy the CPU.
Three: scheduling policy :( focus) ---- "to process their priorities and scheduling policies" based scheduling policy. 1: The overall scheduling strategy: the system will be based on priority and scheduling policy it uses for each process, through some kind of algorithm to calculate an operation of each process "weights" every time scheduling system, according to this right the value of scheduling, the highest weight, the first to be scheduled. However, this weight is not static, but over time the implementation process to be executed diminishes, so, lower the original weight of the process can also have a chance to be implemented (to ensure "fairness" of the process scheduling). When the weights of all processes are reduced to 0 (Note: If using SCHED_FIFO thread or, SCHED_RR scheduling policy will be mentioned below, it is not possible weights all processes have become 0, using at least two scheduling weights process strategy will remain at least 1000), the system will be re-evaluated once the weights of all processes, scheduling repeat the process again. **** Note: It is because when the weights are calculated, taking into account priority and scheduling policy it uses each process, so that, LINUX kernel scheduling policy is "to process their priorities and scheduling policies." scheduling strategy based.
2: Process own scheduling policy: In order to meet different needs, LINUX kernel designed three different process scheduling policy:
SCHED_FIFO -------- suitable for stronger requirements on timing, and every run used in a relatively short time, real-time applications for this strategy.
SCHED_RR ----------- "RR" is the Round Robin (rotation) means for relatively large program, each run takes a long time to process.
SCHED_OTHER ------ traditional scheduling policy for the interactive time-sharing applications. In addition, each process can set their own scheduling policy sched_setscheduler call through the system ().
Four: Through the above analysis of LINUX process of scheduling strategy can be drawn from this scheduling strategy can not guarantee real-time requirements, it is necessary to make a so-called real-time patches. However, in the current situation we can not change the scheduling strategy, in order to improve real-time, you can take the following measures :
1: CPU time slice division smaller. Drawbacks of doing so is the process of scheduling will be very frequent, increasing the cost because the process of scheduling and cost.
2: real-time process high priority (1-99).
3: real-time process using SCHED_FIFO scheduling policy, but they want to sleep () and other similar operations .
