Operating System Examples - Scheduling

References r er/ch10.html r bangalore.org/blug/meetings/200401/scheduler- 2.6.pdf r cheduler.pdf r CFS.txt r Windows Operating System Internals Curriculum Development Kit, developed by Solomon, Russinovich and Polze

Solaris r Solaris uses priority-based thread scheduling r Each thread belongs to one of six classes m Time sharing m Interactive m Real time m System m File share m Fixed priority r Default class: time sharing r Within each class there are different priorities r Each class uses different scheduling algorithms

Solaris r Time sharing scheduling algorithm m Dynamically alters priorities of processes m Uses a multilevel feedback queue m The higher the priority the smaller the time slice m The lower the priority the larger the time slice m Interactive processes typically have higher priority (good response time) m CPU-bound processes have lower priority (good throughput)

Solaris r Time sharing scheduling algorithm m If a thread has used its entire time quantum without blocking its priority is changed m The priority of a thread that is returning from sleeping (e.g. waiting for I/O) has its priority increased r Interactive scheduling algorithm m Similar to time sharing but give window managers (e.g., KDE, GNOME) a higher priority

Solaris Dispatch Table

Solaris r Real-time class m Highest priority m A thread in this class will before a process in any other class m Few processes belong in this class r System class m Kernel threads are assigned to this class e.g., scheduler and paging daemons

Solaris r Fixed-priority m Relatively new m Same number of priorities as time sharing but no dynamic adjustment of priorities r Fair-share m Uses CPU shares instead of priorities m A share is an indicator of entitlement

Solaris r Each scheduling class includes a set of priorities r However, the scheduler converts the class- specific priorities into global priorities r The thread with the highest global priority is chosen to run

Solaris Scheduling

Windows XP r The scheduler is called a dispatcher r 32-level priority scheme r Priorities are divided into two classes: m Variable class: priorities 1 to 15 m Real-time class: priorities 16 to 31 r There is a queue for each priority r The dispatcher traverses the set of queues from highest to lowest until it finds a thread that is ready to run r If there are no processes ready to run the dispatcher executes the idle thread

Windows XP Scheduling r Processes are given a priority class upon creation: m REALTIME_PRIORITY_CLASS m HIGH_PRIORITY_CLASS m ABOVE_NORMAL_PRIORITY_CLASS m NORMAL_PRIORITY_CLASS m BELOW_NORMAL_PRIORITY_CLASS m IDLE_PRIORITY_CLASS r Priorities in all classes except the REALTIME_PRIORITY class can change

Windows XP Scheduling r A thread within a given priority class has a relative priority within the class: m TIME_CRITICAL m HIGHEST m ABOVE_NORMAL m NORMAL m BELOW_NORMAL m LOWEST m IDLE

Windows XP r Each thread has a base priority representing a value in the priority range for the class that the thread belongs r The priority of each thread is based on both the priority class it belongs to and its relative priority within that class r As with Solaris the classes and the priorities in the classes are mapped to a global priority

Windows XP Priorities

Windows XP r Priority changes for threads in the variable class m Time quantum expires: Priority is lowered but not below the base priority m Thread switches from blocked to running: Priority is increased The amount depends on what the thread was doing Keyboard I/O gets a large increase while disk I/O gets a moderate increase

Windows XP r Windows XP distinguishes between the foreground process that is currently selected on the screen and the background processes that are not currently selected r The strategy tends to give good response times to interactive threads that are using the mouse and windows r The I/O devices are kept busy

Linux Scheduling r The Linux kernel internally represents processes and threads as tasks via the task_struct r Linux uses task_struct (process control block)to represent any execution context m A single-threaded process will be represented with one task structure m A multithreaded process will have one task structure for each of the user-level threads

Linux Scheduling r Constant order O(1) scheduling time r Two priority ranges: time-sharing and real- time r Real-time range from 0 to 99 and nice value from 100 to 140 r Linux (unlike Solaris) assigns higher priority tasks longer time quanta and lower priority tasks shorter time quanta

Linux Scheduling Priorities and Time-slice length

Linux Scheduling r A runnable task is considered for execution on the CPU as long as it has time remaining in its time slice r When a task has exhausted its time slice, it is considered expired and is not eligible for execution again until all other tasks have all exhausted their time slice

Linux Scheduling r The kernel maintains a list of all runnable tasks in a runqueue data structure r In a multi-core machine there is a runqueue for each processor r Each runqueue consists of two priority arrays: m Active: Contains all tasks with time remaining in their time slices m Expired: Contains all expired tasks r The active, expired queues are indexed according to priority

Linux Scheduling List of Tasks Indexed According to Priorities

Linux Scheduling r The scheduler chooses the task with the highest priority from the active array for execution r When there are no more tasks in the active array, the expired array becomes the active array and the active array becomes the expired array.

Linux Scheduling r The scheduler chooses the task with the highest priority from the active array for execution r A task’s dynamic priority is recalculated when the task has exhausted its time quantum and is to be moved to the expired array

Linux Scheduling r Linux tries to give a higher priority to interactive tasks r The scheduler somehow needs to measure the interactivity of a process r Interactive processes sleep more than others

Linux Scheduling r The scheduler keeps track of the average amount of time a task sleeps vs average amount of time task uses CPU m Use the sleep_avg variable r When a process wakes the time spent sleeping is added to its sleep_avg; r The run time is subtracted from sleep_avg r The higher the value of sleep_avg the more I/O bound it is

Question Can Linux processes starve?

Case Study Discussion r Basic idea for schedule user processes is the same for all systems: m Lower priority for CPU bound process m Increase priority for I/O bound process r The scheduling in Solaris / Linux is more concerned about fairness. m More popular as the OSes for servers. r The scheduling in Window XP is more concerned about user perceived performance. m More popular as the OS for personal computers.

Summary r We have examined scheduling in several contemporary operating systems