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 | | |
| | | | | | | | | |