1 / 59

Chapter 6 Scheduling

Chapter 6 Scheduling. Overview. CPU scheduling is the basis of multiprogrammed operating systems By switching the CPU among processes The OS can make the computer more productive On operating systems that support threads

Lucy
Télécharger la présentation

Chapter 6 Scheduling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 6 Scheduling

  2. Overview • CPU scheduling is the basis of multiprogrammed operating systems • By switching the CPU among processes • The OS can make the computer more productive • On operating systems that support threads • It is kernel-level threads that are in fact being scheduled by the operating system • Not processes

  3. Basic Concepts • In a single-processor system • Only one process can run at a time • Others must wait until the CPU is free and can be rescheduled • The objective of multiprogramming • To have some process running at all times • To maximize CPU utilization • The idea is relatively simple • A process is executed until it must wait • Typically for the completion of some I/O request • In a simple computer system • The CPU just sits idle

  4. Basic Concepts (cont.) • All this waiting time is wasted • No useful work is accomplished • With multiprogramming • Try to use this time productively • Several processes are kept in memory at one time • When one process has to wait • The OS takes the CPU away from that process • Gives the CPU to another process • This pattern continues • Every time one process has to wait • Another process can take over use of the CPU • Scheduling of this kind is a fundamental operating-system function

  5. Basic Concepts (cont.) • Almost all computer resources are scheduled before use • The CPU is certainly one of the primary computer resources • The scheduling is central to operating-system design

  6. CPU–I/O Burst Cycle • The success of CPU scheduling depends on an observed property of processes • Process execution consists of a cycle of CPU execution and I/O wait • Processes alternate between these two states • Process execution begins with a CPU burst • Followed by an I/O burst, which is followed by another CPU burst, then another I/O burst, and so on • Eventually, the final CPU burst ends with a system request to terminate execution • The durations of CPU bursts have been measured extensively • Vary greatly from process to process

  7. CPU–I/O Burst Cycle (cont.)

  8. CPU–I/O Burst Cycle (cont.) • And from computer to computer • Tend to have a frequency curve • Characterized as exponential or hyperexponential • With a large number of short CPU bursts and a small number of long CPU bursts • An I/O-bound program typically has many short CPU bursts • A CPU-bound program may have a few long CPU bursts • This distribution can be important in the selection of an appropriate CPU-scheduling algorithm

  9. CPU–I/O Burst Cycle (cont.)

  10. CPU Scheduler • Whenever the CPU becomes idle • The operating system must select one of the processes in the ready queue to be executed • The selection process is carried out by the short-term scheduler, or CPU scheduler • The scheduler selects a process from the processes in memory ready to execute • Allocates the CPU to that process • The ready queue is not necessarily a first-in, first-out (FIFO)queue • Can be implemented as a FIFO queue, a priority queue, a tree, or simply an unordered linked list • All the processes in the ready queue are lined up

  11. CPU Scheduler (cont.) • Waiting for a chance to run on the CPU • The records in the queues are generally process control blocks (PCBs) of the processes

  12. Preemptive Scheduling • CPU-scheduling decisions may take place under the following four circumstances • When a process switches from the running state to the waiting state • e.g., As the result of an I/O request or an invocation of wait() for the termination of a child process • When a process switches from the running state to the ready state • e.g., When an interrupt occurs • When a process switches from the waiting state to the ready state • e.g., At completion of I/O • When a process terminates

  13. Preemptive Scheduling (cont.) • For situations 1 and 4 • There is no choice in terms of scheduling • A new process must be selected for execution • There is a choice for situations 2 and 3 • When scheduling takes place only under circumstances 1 and 4 • The scheduling scheme is nonpreemptive or cooperative • Otherwise, it is preemptive • Under nonpreemptive scheduling • Once the CPU has been allocated to a process • The process keeps the CPU until it releases the CPU either by terminating or by switching to the waiting state

  14. Preemptive Scheduling (cont.) • Cooperative scheduling is the only method that can be used on certain hardware platforms • Does not require the special hardware needed for preemptive scheduling • e.g., A timer • Preemptive scheduling can result in race conditions • When data are shared among several processes • Consider that two processes that share data • While one process is updating the data, it is preempted so that the second process can run • The second process then tries to read the data, which are in an inconsistent state

  15. Preemptive Scheduling (cont.) • Preemption also affects the design of the operating-system kernel • During the processing of a system call • The kernel may be busy with an activity on behalf of a process • Such activities may involve changing important kernel data, e.g., I/O queues • If the process is preempted in the middle of these changes • The kernel or the device driver needs to read or modify the same structure • Chaos ensues • Certain OSes, including most versions of UNIX

  16. Preemptive Scheduling (cont.) • Deal with this by waiting for a system call to complete • Or for an I/O block to take place before doing a context switch • Ensures that the kernel structure is simple • The kernel will not preempt a process while the kernel data structures are in an inconsistent state • This kernel-execution model is a poor one for supporting real-time computing • Tasks must complete execution within a given time frame • Interrupts can occur at any time • Cannot always be ignored by the kernel

  17. Preemptive Scheduling (cont.) • The sections of code affected by interrupts must be guarded from simultaneous use • The operating system needs to accept interrupts at almost all times • Otherwise, input might be lost or output overwritten • So that these sections of code are not accessed concurrently by several processes • Disable interrupts at entry • Reenable interrupts at exit • Sections of code that disable interrupts do not occur very often • Typically contain few instructions

  18. Dispatcher • The dispatcher is the module • Gives control of the CPU to the process selected by the short-term scheduler • This function involves • Switching context • Switching to user mode • Jumping to the proper location in the user program to restart that program • Should be as fast as possible • Invoked during every process switch • The dispatch latency • The time the dispatcher takes to stop one process and start another running

  19. Scheduling Criteria • Different CPU-scheduling algorithms have different properties • The choice of a particular algorithm may favor one class of processes over another • Must consider the properties of the various algorithms in choosing which algorithm to use • Many criteria have been suggested for comparing CPU-scheduling algorithms • How algorithm is judged to be best • CPU utilization • To keep the CPU as busy as possible • Conceptually, CPU utilization can range from 0 to 100 percent

  20. Scheduling Criteria (cont.) • In a real system, it should range from 40 percent for a lightly loaded system to 90 percent for a heavily loaded system • Throughput • If the CPU is busy executing processes, then work is being done • One measure of work is the number of processes that are completed per time unit, called throughput • For long processes, may be one process per hour • For short ones, may be 10 processes per second • Turnaround time • From the point of view of a process, the important criterion is how long it takes to execute that process • The interval from the time of submission of a process to the time of completion is the turnaround time

  21. Scheduling Criteria (cont.) • Turnaround time is the sum of the periods spent waiting to get into memory, waiting in the ready queue, executing on the CPU, and doing I/O • Waiting time • The CPU-scheduling algorithm does not affect the amount of time during which a process executes or does I/O • Affects only the amount of time that a process spends waiting in the ready queue • Waiting time is the sum of the periods spent waiting in the ready queue • Response time • In an interactive system, turnaround time may not be the best criterion • A process can produce some output fairly early

  22. Scheduling Criteria (cont.) • And can continue computing new results while previous results are being output to the user • Another measure is the time from the submission of a request until the first response is produced • Response time is the time a process takes to start responding • Not the time it takes to output the response • The turnaround time is generally limited by the speed of the output device • Desire to maximize CPU utilization and throughput • And to minimize turnaround time, waiting time, and response time • In most cases, optimize the average measure

  23. Scheduling Criteria (cont.) • Under some circumstances • Prefer to optimize the minimum or maximum values rather than the average • e.g., To guarantee that all users get good service, may want to minimize the maximum response time • For interactive systems • Such as desktop systems • More important to minimize the variance in the response time than to minimize the average • A system with reasonable and predictable response time may be considered more desirable than a system that is faster on the average but is highly variable • Little work has been done on CPU-scheduling algorithms that minimize variance

  24. Scheduling Criteria (cont.) • The first problem is defining the criteria to be used in selecting an algorithm • To select an algorithm • Must first define the relative importance of these elements • The criteria may include several measures • Maximizing CPU utilization under the constraint that the maximum response time is 1 second • Maximizing throughput such that turnaround time is on averag) linearly proportional to total execution time

  25. Thread Scheduling • User-level threads are managed by a thread library • The kernel is unaware of them • To run on a CPU • User-level threads must ultimately be mapped to an associated kernel-level thread • This mapping may be indirect and may use a lightweight process (LWP)

  26. Contention Scope • One distinction between user-level and kernel-level threads • How they are scheduled • On systems implementing the many-to-one and many-to-many models • The thread library schedules user-level threads to run on an available LWP • Known as process-contention scope (PCS) • Competition for the CPU takes place among threads belonging to the same process • The thread library schedules user threads onto available LWPs • Do not mean that the threads are actually running on a CPU

  27. Contention Scope (cont.) • That will require the operating system to schedule the kernel thread onto a physical CPU • To decide which kernel-level thread to schedule onto a CPU • The kernel uses system-contention scope (SCS) • Competition for the CPU takes place among all threads in the system • Systems using the one-to-one model schedule threads using only SCS • Such as Windows, Linux, and Solaris • PCS is done according to priority • The scheduler selects the runnable thread with the highest priority to run

  28. Contention Scope (cont.) • User-level thread priorities are set by the programmer • Not adjusted by the thread library • Some thread libraries may allow the programmer to change the priority of a thread • PCS will typically preempt the thread currently running in favor of a higher-priority thread • There is no guarantee of time slicing among threads of equal priority

  29. Pthread Scheduling • The POSIX Pthread API allows specifying PCS or SCS during thread creation • Pthreads identifies two contention scope values • PTHREAD_SCOPE_PROCESS schedules threads using PCS scheduling • PTHREAD_SCOPE_SYSTEM schedules threads using SCS scheduling • On systems implementing the many-to-many model • The PTHREAD_SCOPE_PROCESS policy schedules user-level threads onto available LWPs • The number of LWPs is maintained by the thread library, perhaps using scheduler activations

  30. Pthread Scheduling (cont.) • The PTHREAD_SCOPE_SYSTEM scheduling policy will create and bind an LWP for each user-level thread on many-to-many systems • Effectively mapping threads using the one-to-one policy • The Pthread IPC provides two functions • For getting and setting the contention scope policy pthread_attr_setscope(pthread_attr_t* attr, int scope) pthread_attr_getscope(pthread_attr_t* attr, int *scope) • The first parameter for both functions contains a pointer to the attribute set for the thread

  31. Pthread Scheduling (cont.) • The second parameter for the pthread_attr_setscope() function is passed either the PTHREAD_SCOPE_ SYSTEM or the PTHREAD_SCOPE_PROCESS value • Indicating how the contention scope is to be set • For pthread_attr_getscope() • This second parameter contains a pointer to an int value set to the current value of the contention scope • If an error occurs, each of these functions returns a nonzero value • A Pthread scheduling API • The program first determines the existing contention scope • Then sets it to PTHREAD_SCOPE_SYSTEM • Creates five separate threads

  32. Pthread Scheduling (cont.) • Will run using the SCS scheduling policy • On some systems, only certain contention scope values are allowed • e.g., Linux and Mac OS X systems allow only PTHREAD_SCOPE_SYSTEM

  33. Pthread Scheduling (cont.)

  34. POSIX Real-Time Scheduling • The POSIX standard also provides extensions for real-time computing • POSIX.1b • Related to scheduling real-time threads • POSIX defines two scheduling classes for real-time threads • SCHED_FIFO • SCHED_FIFO schedules threads according to a first-come, first-served policy using a FIFO queue • No time slicing among threads of equal priority • The highest-priority real-time thread at the front of the FIFO queue will be granted the CPU until it terminates or blocks

  35. POSIX Real-Time Scheduling (cont.) • SCHED_RR • Uses a round-robin policy • Similar to SCHED_FIFO except that it provides time slicing among threads of equal priority • POSIX provides one more scheduling class • SCHED_ OTHER • Its implementation is undefined and system specific • May behave differently on different systems • The POSIX API specifies the two functions • For getting and setting the scheduling policy Pthread_attr_getsched_policy(pthread_attr_t *attr, int *policy) pthread_attr_setsched_policy(pthread_attr_t *attr, int policy)

  36. POSIX Real-Time Scheduling (cont.) • The first parameter to both functions is a pointer to the set of attributes for the thread • The second parameter is either a pointer to an integer that is set to the current scheduling policy for pthread_attr_getsched_policy() • Or an integer value: SCHED_FIFO, SCHED_RR, or SCHED_OTHER for the pthread_attr_setsched_policy() function • Both functions return nonzero values if an error occurs • A POSIX Pthread program using this API • This program first determines the current scheduling policy • Then sets the scheduling algorithm to SCHED_FIFO

  37. POSIX Real-Time Scheduling (cont.)

  38. POSIX Real-Time Scheduling (cont.)

  39. Linux Scheduling • To schedule tasks with the Linux scheduler • Prior to Version 2.5, Linux ran a variation of the traditional UNIX scheduling algorithm • Resulted in poor performance for systems with a large number of runnable processes • With Version 2.5 of the kernel, the scheduler was overhauled to include a scheduling algorithm • Known as O(1) • Ran in constant time regardless of the number of tasks in the system • Led to poor response times for the interactive processes common on many desktop systems • During development of the 2.6 kernel, the scheduler was again revised

  40. Linux Scheduling (cont.) • In release 2.6.23 of the kernel • The Completely Fair Scheduler (CFS) became the default Linux scheduling algorithm • Scheduling in the Linux system is based on scheduling classes • Each class is assigned a specific priority • By using different scheduling classes • The kernel can accommodate different scheduling algorithms based on the needs of the system and its processes • e.g., The scheduling criteria for a Linux server may be different from those for a mobile device running Linux • To decide which task to run next • The scheduler selects the highest-priority task belonging to the highest-priority scheduling class

  41. Linux Scheduling (cont.) • Standard Linux kernels implement two scheduling classes • A default scheduling class using the CFS scheduling algorithm • A real-time scheduling class • New scheduling classes can be added • The CFS scheduler assigns a proportion of CPU processing time to each task • Rather than using strict rules to associate a relative priority value with the length of a time quantum • This proportion is calculated based on the nice value assigned to each task

  42. Linux Scheduling (cont.) • Nice values range from -20 to +19 • A numerically lower nice value indicates a higher relative priority • Tasks with lower nice values receive a higher proportion of CPU processing time than tasks with higher nice values • The default nice value is 0 • The term nice comes from the idea • If a task increases its nice value from, say, 0 to +10, it is being nice to other tasks in the system by lowering its relative priority • CFS does not use discrete values of time slices • Instead identifies a targeted latency

  43. Linux Scheduling (cont.) • An interval of time during which every runnable task should run at least once • Proportions of CPU time are allocated from the value of targeted latency • Having default and minimum values • Targeted latency can increase • If the number of active tasks in the system grows beyond a certain threshold • The CFS scheduler does not directly assign priorities • It records how long each task has run by maintaining the virtual run time of each task • Using the per-task variable vruntime

  44. Linux Scheduling (cont.) • The virtual run time is associated with a decay factor based on the priority of a task • Lower-priority tasks have higher rates of decay than higher-priority tasks • For tasks at normal priority with nice values of 0 • Virtual run time is identical to actual physical run time • e.g., If a task with default priority runs for 200 milliseconds, its vruntime will also be 200 milliseconds • If a lower-priority task runs for 200 milliseconds • Its vruntime will be higher than 200 milliseconds • If a higher-priority task runs for 200 milliseconds • Its vruntime will be less than 200 milliseconds • To decide which task to run next • The scheduler simply selects the task that has the smallest vruntime value

  45. Linux Scheduling (cont.) • A higher-priority task that becomes available to run can preempt a lower-priority task • The CFS scheduler provides an efficient algorithm for selecting a task to run next • Each runnable task is placed in a red-black tree • A balanced binary search tree whose key is based on the value of vruntime

  46. Linux Scheduling (cont.) • As a task is runnable, it is added to the tree • If a task is not runnable, it is removed • e.g., If it is blocked while waiting for I/O • Tasks that have been given less processing time are toward the left side of the tree • Smaller values of vruntime • Tasks that have been given more processing time are on the right side • Based on the properties of a binary search tree • The leftmost node has the smallest key value • The task with the highest priority • The red-black tree is balanced • Discover the leftmost node will require O(lg N) operations, and N is the number of nodes in the tree

  47. Linux Scheduling (cont.) • For efficiency reasons, the Linux scheduler caches this value in the variable rb_leftmost • Thus determining which task to run next requires only retrieving the cached value • Two tasks have the same nice values • One task is I/O-bound • Will run only for short periods before blocking for additional I/O • The other is CPU-bound • Will exhaust its time period whenever it has an opportunity to run on a processor • The value of vruntime will eventually be lower for the I/O-bound task than for the CPU-bound task • Giving the I/O-bound task higher priority than the CPU-bound task

  48. Linux Scheduling (cont.) • If the CPU-bound task is executing when the I/O-bound task becomes eligible to run • The I/O-bound task will preempt the CPU-bound task • e.g., AS I/O the task is waiting for becomes available • Linux also implements real-time scheduling using the POSIX standard • Any task scheduled using either the SCHED_FIFO or the SCHED_RR real-time policy runs at a higher priority than normal tasks • Linux uses two separate priority ranges • One for real-time tasks and a second for normal tasks • Real-time tasks are assigned static priorities within the range of 0 to 99 • Normal tasks are assigned priorities from 100 to 139

  49. Linux Scheduling (cont.) • The two ranges map into a global priority scheme • Numerically lower values indicate higher relative priorities • Normal tasks are assigned a priority based on their nice values • A value of -20 maps to priority 100 • A nice value of +19 maps to 139 • Another aspect of scheduling is also important to Linux • The running of the various kernel tasks

  50. Linux Scheduling (cont.) • Kernel tasks encompass both tasks • Tasks requested by a running process • Tasks that execute internally on behalf of the kernel itself, like tasks spawned by Linux’s I/O subsystem • Linux has two separate process-scheduling algorithms • One is a time-sharing algorithm for fair, preemptive scheduling among multiple processes • The other is designed for real-time tasks • Absolute priorities are more important than fairness • Earlier schedulers does not maintain fairness among interactive tasks • Particularly on systems like desktops and mobile devices

More Related