7.1 Scheduling Policy | |||||||||
· fulfill several conflicting objectives: | |||||||||
fast process response time | |||||||||
good throughput for background jobs | |||||||||
avoidance of process starvation | |||||||||
reconciliation of the needs of low- and high-priority processes | |||||||||
· when and how to select a new process to run is called scheduling policy | |||||||||
· Linux scheduling is | |||||||||
based on the time sharing technique | |||||||||
based on ranking processes according to their priority | |||||||||
process priority is dynamic | |||||||||
· I/O-bound/CPU-bound | |||||||||
· three classes of processes: | |||||||||
Interactive processes | |||||||||
Batch processes | |||||||||
Real-time processes | |||||||||
· Process Preemption | |||||||||
TIF_NEED_RESCHED flag in the thread_info structure | |||||||||
a preempted process is not suspended, because it remains in the TASK_RUNNING state | |||||||||
· How Long Must a Quantum Last? | |||||||||
The quantum duration is critical for system performance: | |||||||||
it should be neither too long nor too short. | |||||||||
If the average quantum duration is too short, the system overhead | |||||||||
caused by process switches becomes excessively high | |||||||||
In some cases, however, a very long quantum duration d | |||||||||
egrades the responsiveness of the system | |||||||||
· The rule of thumb adopted by Linux is choose a duration as long as possible, | |||||||||
while keeping good system response time | |||||||||
7.2. The Scheduling Algorithm | |||||||||
earlier versions of Linux | |||||||||
the kernel scanned the list of runnable processes, | |||||||||
computed their priorities, and selected the "best" process to run | |||||||||
drawback:time spent in choosing the best process | |||||||||
depends on the number of runnable processes | |||||||||
· in Linux 2.6 | |||||||||
scales well with the number of runnable processes, | |||||||||
because it selects the process to run in constant time | |||||||||
scales well with the number of processors | |||||||||
because each CPU has its own queue of runnable processes | |||||||||
does a better job of distinguishing interactive processes and batch processes | |||||||||
· The scheduler always succeeds in finding a process to be executed; | |||||||||
in fact, there is always at least one runnable process: the swapper process, | |||||||||
which has PID 0 and executes only when the CPU cannot execute other processes | |||||||||
· scheduling classes : | |||||||||
SCHED_FIFO | |||||||||
A First-In, First-Out real-time process | |||||||||
leaves the process descriptor in its current position in the runqueue list | |||||||||
SCHED_RR | |||||||||
A Round Robin real-time process | |||||||||
puts the process descriptor at the end of the runqueue list | |||||||||
SCHED_NORMAL | |||||||||
A conventional, time-shared process | |||||||||
· Scheduling of Conventional Processes | |||||||||
static priority,ranging from 100 (highest priority) to 139 (lowest priority) | |||||||||
A new process always inherits the static priority of its parent | |||||||||
a user can change the static priority of the processes | |||||||||
nice( ) and setpriority( ) system calls | |||||||||
· Base time quantum | |||||||||
Base time quantum | = | (140 - static priority) * 20 if static priority < 120 | |||||||
(milisecond) | (140 - static priority) * 5 if static priority >= 120 | ||||||||
· Dynamic priority and average sleep time | |||||||||
dynamic priority,ranging from 100 (highest priority) to 139 (lowest priority) | |||||||||
The dynamic priority is the number actually looked up by the scheduler | |||||||||
when selecting the new process to run | |||||||||
dynamic priority = max (100, min ( static priority - bonus + 5, 139)) | |||||||||
bonus :ranging from 0 to 10,depends on average sleep time of the process | |||||||||
value less than 5 | penalty | ||||||||
greater than 5 | premium | ||||||||
the average sleep time is the average number of | |||||||||
nanoseconds that the process spent while sleeping | |||||||||
The average sleep time is also used by the scheduler to determine | |||||||||
whether a given process should be considered interactive or batch | |||||||||
interactive | |||||||||
dynamic priority <= 3 * static priority / 4 + 28 | |||||||||
equivalent to bonus - 5 >= static priority / 4 - 28 | |||||||||
The expression static priority / 4 - 28 is called the interactive delta | |||||||||
It should be noted that it is far easier for high priority than | |||||||||
for low priority processes to become interactive | |||||||||
· Active and expired processes | |||||||||
To avoid process starvation | |||||||||
when a process finishes its time quantum, it can be replaced by a lower priority | |||||||||
process whose time quantum has not yet been exhausted. To implement | |||||||||
this mechanism, the scheduler keeps two disjoint sets of runnable processes: | |||||||||
Active Processes:These runnable processes have not yet | |||||||||
exhausted their time quantum and are thus allowed to run | |||||||||
Expired processes:These runnable processes have exhausted their time quantum | |||||||||
and are thus forbidden to run until all active processes expire | |||||||||
However, the general schema is slightly more complicated than this, because the scheduler tries to | |||||||||
boost the performance of interactive processes. An active batch process that finishes | |||||||||
Its time quantum always becomes expired. An active interactive process that finishes | |||||||||
its time quantum usually remains active: the scheduler refills its time quantum and leaves | |||||||||
it in the set of active processes. However, the scheduler moves an interactive process | |||||||||
that finished its time quantum into the set of expired processes if the eldest expired process | |||||||||
has already waited for a long time, or if an expired process has higher static priority (lower value) | |||||||||
than the interactive process. As a consequence, the set of active processes will eventually | |||||||||
become empty and the expired processes will have a chance to run. | |||||||||
· Scheduling of Real-Time Processes | |||||||||
ranging from 1 (highest priority) to 99 (lowest priority),are always considered active | |||||||||
A real-time process is replaced by another process only | |||||||||
when one of the following events occurs: | |||||||||
· The process is preempted by another process having higher real-time priority. | |||||||||
· The process performs a blocking operation, and it is put to sleep | |||||||||
(in state TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE). | |||||||||
· The process is stopped (in state TASK_STOPPED or TASK_TRACED), | |||||||||
or it is killed (in state EXIT_ZOMBIE or EXIT_DEAD). | |||||||||
· The process voluntarily relinquishes the CPU by invoking the sched_yield( ) system call | |||||||||
· The process is Round Robin real-time (SCHED_RR), and it has exhausted its time quantum | |||||||||
the duration of the base time quantum of Round Robin real-time processes does not | |||||||||
depend on the real-time priority, but rather on the static priority of the process | |||||||||
Understanding the linux kernel-ch7-Process Scheduling
最新推荐文章于 2025-06-13 19:58:56 发布