T he Implementation and Evaluation of a CPU Scheduling Simulator

1. The Implementation and Evaluation of a CPU Scheduling Simulator Michael Jugan, Clay Taylor, XuejuanZhang

2. Background • CPU scheduling • A fundamental task of an operating system • OS decides when, and for how long, each process has access to the CPU • Problem • Difficult to choose the best scheduling algorithm for a system • Many scheduling algorithmsand workloads • Solution • Create a process-driven scheduling simulator • Evaluate scheduling algorithms using multiple workloads

3. Challenges • Creating a realistic simulator • Must balance realism and complexity • Performing evaluations • “Best” scheduler depends on the system’s requirements • Must use multiple metrics and workloads • Thorough testing will indicate which algorithms are best for certain situations.

4. Related Work • LinSched [1] • Developed by a PhD candidate at the University of North Carolina • Used by Google • Runs the scheduling portions of Linux’s kernel in user space • Extremely realistic • Designed for systems programmers

5. Related Work • CPU Scheduling Simulator • a framework that allows you to quickly and easily design and gather metrics for custom CPU scheduling strategies [2] • Written in C# using Microsoft Visual Studio • Over 6,300 downloads • No UNIX equivalent could be found

6. Design • Reads input • Runs simulation • tracks statistics • Outputs results

7. Design Process script • Declares processes to run • Name • Length • Issue time

8. Design Issued processes • Simulator determines when each process is issued • Processes want access to the CPU • Eligible to be scheduled

9. Design Scheduler • Tells the simulator which process should be executed by the CPU and for how much time

10. Design Scheduling Algorithms • First-in first-out (FIFO) • Shortest job first (SJF) • Runs the process with the least amount of remaining time. • Round robin (RR) • Cycles through the processes and allots each a fixed amount of time known as a time-slice.

11. Design Scheduling Algorithms • Priority queuing (PQ) • Earliest deadline first (EDF) • Multi-level feedback queuing (MLFQ) • Several queues • Highest priority queue has shortest time-slice • Selects the first process in the highest priority queue • Process runs for a time-slice, then moves to a lower priority queue

12. Design Outputs • Detailed trace • Describes scheduler’s actions and process’ stats • Useful for debugging and understanding the scheduling algorithms

13. Design Outputs • Results summary • CPU utilization • % of runtime during which the CPU is actively running a process • Blocking time • Process switching time • Queuing time • time a process waits to be run • Turnaround time • time to complete a process • Percent of deadlines met • Total runtime

14. Design – Advanced Features • Process blocking • Processes may be configured to periodically block. • Simulates blocking I/O • Regular preemption • The scheduler may notify the simulator to swap the active process • Example: PQ scheduler may preempt the active process if a higher priority process is recently issued. • Blocking preemption • The scheduler automatically deactivates the active process if it begins to block. • Context switching overhead • Idle cycles when the active process changes

15. Implementation • C++ using object-oriented design principles • Designed for UNIX • Simple to port to Windows • Important detail: • Simulator’s time unit: “cycle” • Does not truly represent an actual CPU’s cycle • Real cycle counts should be scaled down

16. Implementation – Process Scripts • Two sections • Process definitions • Name • Properties • Issue times • Process name and issue time • Benefits: • Naming - easier to interpret results • Process settings can be modified on one line

18. Implementation – Simulator Class • Two public methods: • LoadScript • One argument • the name of a process script • Opens and reads the process script’s contents • Creates Process objects • Run • Three optional parameters • booltraceModeEnabled • boolpreemptBlocksEnabled • unsigned long procSwitchCycles • Performs the simulation • Interacts closely with the Scheduler object

19. Implementation – Scheduler Class • Base class • Three empty virtual methods • void AddProcess(Process * p){} • Process *GetNextProcess(){} • boolShouldPreempt(Process * active_process){} • Methods implemented by derived classes • class FIFO: public Scheduler • class SJF: public Scheduler • etc.

20. Implementation – Programs • Schedule_sim • Command-line based interface to the Simulator class • Script_gen • Helps create process scripts

21. Implementation – Schedule_sim • Four commands: • LOAD_SCRIPT script name • SET_PARAMS traceModeEnabledpreemptBlocksEnabledprocSwitchCycles • RUN • HELP

22. /cs560-scheduling> ./schedule_sim ~ … …

24. Implementation – Script_gen • Two arguments: • Random number seed • Output filename • Prompts user for process information: • Name • Execution time • Blocking period / length • Priority • Deadline • Static issue period • Random issue period • Quantity • Generates process script file issue time = static period + rand() % random period

25. /cs560-scheduling> ./script_gen 21932 output_file ~

26. /cs560-scheduling> vim output_file ~

27. Evaluation • First we verified correctness of results • Used trace mode and small workloads • Did scheduling by hand and compared • Then we evaluated three workloads • Basic workload • Blocking workload • Deadline workload

28. Basic Workload • “Short” processes • Execution time of 100 cycles • Issue period of 100 to 400 cycles • “Long” processes • Execution time of 1000 cycles • Issue period of 1000 to 4000 cycles • 100 of each type issued • Gave “short” processes higher priority • No blocking or deadlines • Tested both with and without overhead

29. Basic Workload - Results

30. Overhead - Results • Same workload and schedulers • Ideal utilization under this workload is ~55%

31. Blocking Workload • Two types of processes • One blocks once after 50 cycles • One blocks four times after 20 cycles • Execution time of 100 cycles • Blocking time of 1000 cycles • Issue period of 1000 to 2000 cycles • More frequent blocker has higher priority • No deadlines or overhead • Tested with and without preemption

32. Blocking Workload - Results

33. Deadline Workload • “Short” processes • Execution time of 10 cycles • Deadline of 100 cycles • Issue period of 50 cycles • “Medium” processes • Execution time of 50 cycles • Deadline of 500 cycles • Issue period of 100 cycles • “Long” processes • Execution time of 100 cycles • Deadline of 1000 cycles • Issue period of 250 cycles • Increasing priority for decreasing deadline • No overhead or blocking

34. Deadline Workload - Results • Meeting all deadlines is theoretically possible • EDF Scheduler achieves 100% deadlines met

35. Conclusion • MLFQ comes out as most well-rounded • Good average queuing and turnaround times • Reasonably resistant to performance drops • Does a good job at meeting most deadlines • SJF and PQ are close to it in performance • However, susceptible to performance drops from blocking • Also unrealistic requirement of knowing process attributes • Favor short processes over long ones • For PQ this was because of how we assigned priority

36. Conclusion (Continued) • RR can emulate preemption on blocking • Also has good “fairness” by not favoring any process type • However, highly sensitive to switching overhead • Longer time slices behave more like FIFO • FIFO favors longer processes • Like SJF/PQ, has issues with blocking without preemption • EDF only one that met all deadlines • If meeting deadlines is required, it is the clear choice

37. References [1] “LinSched: The Linux Scheduler Simulator”: http://www.cs.unc.edu/ ~jmc/linsched/. [Accessed May 4, 2012] [2] “CPU Scheduling Simulator”: http://cpuss.codeplex.com/. [Accessed May 4, 2012]