1. Operating System Examples - Scheduling

2. References r Silberschatz et al, Chapter 5.6, Chapter 22.3.22

3. Note: Process/Thread r A unit of execution is a process r Processes can create a unit of execution called a thread m Threads share data with processes m Operating systems schedule threads in the same way processes are scheduled r We will discuss threads in much greater detail later in the course

4. Solaris

5. r Solaris is a Unix Operating systems originally developed by Sun r Sun was acquired by Oracle in 2010 and so Solaris is sometimes called Oracle Solaris r Solaris was developed as proprietary software r 2005: Sun released most of its code base and thus Solaris became open source r Oracle closed up Solaris

6. Solaris r Platforms: SPARC, i86pc (x86 and x86-64) r Solaris has support for desktop environments but is mainly aimed at the server market r Lots of innovations with Solaris esp under SUN

7. Solaris r Solaris uses priority- based scheduling r Each process belongs to one of six classes m Time sharing m Interactive m Real time m System m File share m Fixed priority r Default scheduling class m time sharing r Within each class: m Different priorities m Different scheduling algorithms r Priority levels from 0 to 169

8. Priorities

9. r Interrupt r Real-time class m Highest priority m Guaranteed response time m Kernel processes (very few) assigned to this class r System class m Kernel processes are assigned to this class e.g., scheduler m Priorities are static

10. Priorities r Time-sharing m Processes can have their priorities adjusted r Fixed-priority m Introduced in Solaris 9 m No dynamic adjustment of priorities r Fair-share m Uses CPU shares instead of priorities m A share is an indicator of entitlement

11. Real-Time Scheduling r Real-time priority queues can be configured to operate with a FIFO- strategy or a Round Robin strategy r Real-time processes can preempt running processes that have lower priority m Tend to be few real-time processes

12. Time Sharing Scheduling Algorithm r Default priority for a user process is time sharing r Priorities are dynamic r Use of a multilevel feedback queue m Each queue represents a different priority level m Time slices (quantum) are associated with a priority queue r Higher priorities  smaller time slice

13. Time Sharing Scheduling Algorithm r Solaris uses a dispatch table r This is used to assign a new priority to a process. Two cases: m Time quantum expired without blocking  Could be a CPU intensive process m Process blocked before time quantum expired r This new priority will be used to determine the process in a priority queue when the process returns to a READY state

14. Solaris Dispatch Table For time- sharing & Interactiv e processes

15. Solaris Dispatch Table r Priority: A higher number indicates a higher priority r Time quantum: There is an inverse relationship between priorities and time quanta r Time quantum expired: The new priority of a process that has used its entire time quantum without blocking r Return from sleep: The priority of a process that is returning from the blocked state (such as waiting for I/O)

16. Scheduling Algorithm r Time sharing scheduling algorithm m If a priority has used its entire time quantum without blocking its priority is changed (with one exception) m The priority of a priority that is returning from sleeping (e.g. waiting for I/O) has its priority increased This allows for better support of interactive processes

17. Interactive Processes r Interactive processes (e.g., window managers) typically have higher priority (good response time) r CPU-bound processes have lower priority (good throughput)

18. Windows 7

19. Windows r Windows refers to a collection of graphical operating systems developed by Microsoft r There are recent versions of Windows for PCs, server computers, smartphones and embedded devices r There is a specialized version of Windows that runs the Xbox One game console r Windows was originally designed for desktop machines

20. Priorities r Similar to that used in Windows XP r The scheduler is called a dispatcher r 32 priorities r Priorities are divided into two classes: m User class: priorities 1 to 15 m Real-time class: priorities 16 to 31 r Priority 0 is used for memory management processes r There is a queue for each priority

21. Selecting a Process r The dispatcher traverses the set of queues from highest to lowest until it finds a process that is ready to run r If there are no processes ready to run the dispatcher executes the idle process r Priority of a preempted process may be modified before being returned to a ready state r Round robin

22. Adjusting Priority r If process was in user class m Time quantum expires: If process is in the user class the priority is lowered m Process switches from blocked to running: Priority is increased The amount depends on what the process was doing Keyboard I/O gets a large increase while disk I/O gets a moderate increase r Some processes always have a low priority e.g., disk fragmenter

23. Adjusting Priority r The priority of a process cannot be lowered passed the base priority (lower threshold value) of the process r Windows 7 distinguishes between the foreground process that is currently selected on the screen and the background processes that are not currently selected m Tends to give good response times to interactive processes that are using the mouse and windows

24. Linux

25. r As of Dec 2015 m Webservers: W3Cook reports that96.5% of web servers run Linux (1.5% run Windows) m Desktops/laptops: 1.5% use Linux m Mobile devices: Android (based on Linux kernel) is used in 80% of all mobile devices m Platform of choice for film industry r Linux is free and open-source r Please note that Linux uses the term “task”

26. History of Linux Scheduler r Linux version 1.2 m Used circular queue for runnable task management m Round-robin m Efficient for adding and removing processes m Fast and Simple

27. History of Linux Scheduler r Linux version 2.2 m Introduced the idea of scheduling class m Permitting scheduling policies for Real-time taslks Non-preemptible tasks Non-real time task

28. History of Linux Scheduler r Linux version 2.4 m Divided time into epochs m Within each epoch, every task was allowed to execute up to its time slice m Applying goodness function to determine which task to execute next m Simple, O(N), inefficient, lack of scalability, weak for real-time systems

29. History of Linux Scheduling r Linux version 2.5 m Implement scheduling algorithms in O(1) time. Scales well to multiple processors, each with many processes. m Problem: Not responsive to interactive applications Complex, error prone logic No guarantee of faireness r Current: Linux version 2.6

30. Linux Scheduling r Linux has these scheduling classes: m Real-time(RT) classes m Completely fair scheduler (CFS) class r Tasks in RT have higher precedence than tasks in the CFS r We will first start with a discussion of nice values which is related to CFS.

31. CFS - move r The Completely Fair Scheduler (CFS) is a significant departure from the traditional UNIX process scheduler. r Runs tasks with the “gravest need” r Tries to guarantee fairness (CPU Usage)

32. Nice Values r A nice value is assigned to each task m Nice values range from -20 to +19 m Lower nice value indicates a higher relative priority m Tasks with lower nice values receive a higher proportion of CPU processing time than tasks with higher nice values m The default nice value is 0

33. Example Use r Let’s say that you want to run a nightly backup script on a server system like a web hosting server r Backup scripts can produce high load and longer latency for other processes m Backup scripts are both CPU and I/O intensive

34. CFS- Time Slice Calculation r CFS identifies a targeted latency (TL) which is an interval of time during which every runnable task should run at least once. r Time slice for a task i: m TL* W i /(Sum of all W i )

35. CFS- Time Slice Calculation r A nice value is mapped to a weight value m Examples: -20 is mapped to 88761, 0 is mapped to 1024 r The general idea is that m Every process that changes nice value up by one level gets 10% less CPU power m Every process that changes nice value down by one gets 10% more CPU power

36. CFS- Time Slice Calculation r The mapping from nice values to weights uses an array r The array contains one entry for each nice level r The multiplier between the entries is 1.25

37. CFS – Time Slice Calculation r Calculating Schedule Latency m There is a lower bound on smallest time slice m Schedule latency is Lower bound * number of processes

38. CFS - Time Slice Calculation r Example m Targeted latency = 20 ms m Two tasks, t 1 and t 2, with nice values of 0 m The weight value for nice 0 is 1,024 m The share for each task is 1024/(1024+1024) = 0.5 and thus each task will have a “time slice” of 10 ms

39. CFS - Time Slice Calculation r Example m Targeted latency = 20 ms m Two tasks, t 1 and t 2, with nice values of 0 and 5 respectively m The weight value for nice 0 is 1,024 and the weight for nice 5 is 335 m The share for task t 1 is 1024/(1024+335) = 0.75 and thus task t 1 will have a “time slice” of 0.75*20 = 15 ms m The share for task t 2 is 335/(1024+335) = 0.25 task t 2 will have a “time slice” of 20*.25 = 5 ms

40. CFS – Picking the next process r Pick process with the weighted minimum runtime so far r The virtual run time (vruntime) of a task is the actual runtime weighted by its niceness r The value of vruntime is used by the scheduler to determine the next process to run m Process with the smallest vruntime is selected to run next

41. CFS – Virtual Runtime r High nice values should result in less CPU time allocated to a process r This implies that vruntime cannot be the same as the real runtime

42. CFS – Virtual Runtime r Example: Assume a process runs for 200 milliseconds m Nice value is 0: vruntime will be 200 milliseconds m Nice value < 0 : vruntime will be less than 200 milliseconds m Nice value > 0 : vruntime will be greater than 200 milliseconds r Smaller nice values results in values of vruntime that grows more slowly than higher nice values

43. CFS – Calculating vruntime r Let t represent the amount of time spent using the CPU when a process has the CPU r vruntime is incremented by m t*weight 0 /weight i where weight 0 is the weight of nice value 0 weight i is the weight of nice value i m We refer to weight 0 /weight i as the decay factor r Weights of nice values are precomputed to avoid runtime overhead

44. CFS Example Weights Nice ValueWeight -53121 1277 01024 1820 5335

45. CFS Example Weights Nice ValueDecay Factor -51024/3121 =.33 1024/1277 =.80 01024/1024 = 1 11024/820 = 1.24 51024/335 = 3.05

46. CFS – Using vruntime r CFS assigns each task a virtual runtime to account for how long a task has run r Example: Assume two tasks t 1 and t 2 with m nice values of 0 m Assume t 1 runs for 200 milliseconds and t 2 runs for 100 milliseconds which is followed by a lot of other tasks m t 2 will be selected before t 1 for execution

47. CFS – Using vruntime r Example: Assume two tasks t 1 and t 2 with m nice values of 0 and 5 respectively m vruntime 0 and vruntime 1 are initially zero m Decay factors of 1 and 3.05 respectively m Assume t 1 runs for 200 milliseconds and t 2 runs for 100 milliseconds which is followed by a lot of other tasks vruntime 0 is 200 milliseconds vruntime 1 is 305 milliseconds m t 1 will be selected before t 2 for execution m Let’s say that t 1 runs again for 200 milliseconds; vruntime 0 is now 400 milliseconds m t 2 will now be selected before t 1 for execution

48. CFS Starvation r Could a process starve? m No r Let’s say that a task t 1 doesn’t get the processor while t 2 always does m At some point t 1 will have a smaller value for vruntime since it is never being incremented.

49. CFS – Process Selection r CFS selects the process with the minimum virtual runtime r Avoids having run queues per priority level r What about a data structure that represents the collection of tasks? m A single queue would be slow m Multiple queues make sense if there are relatively small number of them m There are many values of virtual runtime

50. CFS – RB Trees A red-black (RB) tree is a binary search tree, which means that for each node, the left subtree only contains keys less than the node's key, and the right subtree contains keys greater than or equal to it. A red-black tree has further restrictions which guarantee that the longest root-leaf path is at most twice as long as the shortest root-leaf path. This bound on the height makes RB Trees more efficient than normal BSTs. Operations are in O(log n) time.

51. CFS -- Task Selection The key for each node is the vruntime of the corresponding task. To pick the next task to run, simply take the leftmost node. This node is pointed to by a variable to reduce traversals http://www.ibm.com/developerworks/linux/library/l-completely-fair-scheduler/

52. CFS Task Selection r What if multiple tasks have the same vruntime value? r You can store multiple values in a list at a node with a sequence number indicating its order in the list

53. CFS r No static slices m The switching rate depends on the system load r Each process receives a proportion of the processor’s time m Length depends on how many other processes are running

54. CFS r As a user you can assign nice values greater than zero r You need root to assign nice values less than zero r Optimizing nice values for applications seems rather complex m Yes it can be

55. Linux Scheduler r Linux has these scheduling classes: m Real-time (RT) class m Completely Fair Scheduler (CFS) class r We discussed CFS in detail r Tasks in the RT class have higher precedence than tasks in the CFS r A task stays in a class unless the application requests a different class

56. Linux Scheduler r 140 priority levels: m RT: There are 100 priority lists ranging from 0 to 99. m User tasks: 101-140 (nice values -20 to 19) r Within RT there are are two scheduling policies m SCHED_RR: round-robin m SCHED_FIFO: FIFO r Round-robin has precedence over FIFO

57. Linux Scheduler r Each class has its own run queue m A run queue is a data structure for a collection of processes

58. RT Rules r FIFO m Tasks that that running with this policy are not preempted unless A Higher priority process arrives Blocked m However, 5% of the CPU is reserved for non- FIFO tasks. r RR m Functions as described earlier

59. Scheduler Policies r Scheduling policy is set by sched_setscheduler() r Scheduling policies: m SCHED_FIFO: for special time-critical applications m SCHED_RR round robin scheduling m SCHED_BATCH for CPU-intensive tasks m SCHED_IDLE for low prioritized tasks m SCHED_OTHER: default

60. System Calls Related to Scheduling System CallsDescriptions niceChange the priority of a CFS task getpriorityGet the priority of a process setprioritySet priority of a process sched_getschedulerGet the scheduling policy of a process sched_setschedulerSet the scheduling policy and priority of a process sched_getparamGet the priority of a process sched_setparamSet the priority of a process sched_yieldRelinquish the processor voluntarily sched_get_priority_minGet the minimum priority value for a policy sched_get_priority_maxGet the maximum priority value for a policy sched_rr_get_intervalGet the time quantum value for the RR policy

61. Other

62. MAC OS X r Based on MACH and Unix BSD r Priorities are categorized into priority bands m Normal: Applications m System high priority: Processes with higher priority then Normal m Kernel mode: Reserved for kernel processes m Real-time: For processes that must be guaranteed a slice of CPU time by a particular deadline

63. MAC OS X r Priorities change dynamically m Based on wait time and amount of time that the process has had the processor m Stay within the same priority band r Reschedules every tenth of a second and recomputes priorities once every second r Process will relinquish CPU after time quantum or when it must wait for an I/O completion r Feedback prevents starvation

64. Android r For mobile devices r Today it is the most commonly used platform r Uses Linux for device managers, memory management, process management

65. Summary r We have examined scheduling in several contemporary operating systems