Redline: Cooperative Scheduling of CPU, Memory and I/O Ting Yang, Emery Berger, Scott Kaplan* and Eliot Moss University of Massachusetts Amherst, and Amherst College* MHERST Department of Computer Science
Motivation Computer has limited amount of resources Interact with user and provide services Important things: Responsiveness, interactivity, and availability Each user request Resource requirements CPU, memory, and I/O Expectation: response time, throughput Operating system Manage resources Provide services as user expected However MHERST Department of Computer Science 2
CPU Scheduling Only parameter: nice (priority, weight) Weight distribution, No performance isolation, no QoS Ad-hoc interactivity heuristic: Interactivity trap Static priority for real-time tasks Optimized for Throughput Fairness Responsiveness MHERST Department of Computer Science 3
Need more than CPU Time Need other resources Memory and I/O different components, different policies Memory: recent usage Clock, LRU, SeQ, etc I/O: elevator, sector number, FIFO Anticipatory, deadline, CFQ, etc Does not respect CPU scheduling MHERST Department of Computer Science 4
Redline: An operating system that uses application s specification to drive task scheduling and guide memory and I/O management. Goal: a set of tasks in the system receive resources as specified and are largely immune from Lack of CPU, memory and I/O bandwidth Effect: Provide certain QoS to selected tasks Ensure interactivity and responsiveness Ensure controllability of the system Provide better user experience when system is busy MHERST Department of Computer Science 5
outline Motivation Redline: Specification CPU Scheduling Memory Manager I/O Scheduling Current Status MHERST Department of Computer Science 6
Application Types Three types of applications Response driven (Type A) GUI interface, video/audio, kernel service Arrive at arbitrary interval with arbitrary work length Deadline independent from arrival time Throughput driven (Type B) Batch tasks need to ensure progress Simulation, Research experiments No constraints (Type C) Tasks whose performance user does not care Not critical to the system. MHERST Department of Computer Science 7
Spec for running applications Type A: response time constraints Load: C, Response window: T C/T also indicates CPU share needed Type B: throughput constraints CPU share: P% Type C: fair queuing Weight: W Other stuff Memory, I/O, flags, etc Example: #6:3:100:0:0:1:1:0:0:0# MHERST Department of Computer Science 8
outline Motivation Redline: Specification CPU Scheduling Memory Manager I/O Scheduling Current Status MHERST Department of Computer Science 9
Existing Schedulers Real Time Scheduler GPS Scheduler EDF / RM Knowledge, C/T Strong assumption Strict admission Strong guarantee Low throughput??? EDF + CFS TS / PS / FQ No Knowledge, W No assumption No admission No strict guarantee High throughput MHERST Department of Computer Science 10
Type A: uses two scheduling policy Policy EDF with eligibility control Fair Sharing: CFS Each task: Start time, deadline, quota Renew a cycle if quota used up Eligible tasks: start > now A eligible task with the earliest deadline When a task used up its entitled time Switch to boost mode use CFS for fair sharing Other task may preempt it Become eligible again when now > start time MHERST Department of Computer Science 11
Example P1: 3 / 8 : 1 P2: 2 / 4 : 1 P3: : 1 0 5 10 15 20 0 5 10 15 20 MHERST Department of Computer Science 12
Admission control Every task is given 1ms after fork() If exec(), load spec and check it Otherwise, scheduler check it Based on real CPU load CPU summary window (4 seconds) Actual load, predicted load Difference decayed periodically Admission check New: average over 90%, reject Periodic: all slot over 90%, pick a loser Run as type C task MHERST Department of Computer Science 13
outline Motivation Redline: Specification CPU Scheduling Memory Manager I/O Scheduling Current Status MHERST Department of Computer Science 14
VMM Protect type A pages by a period of time Default: 30 minutes (can change through spec) Evict type C and expired type A pages Type A tasks may book type C pages Type A tasks may reduce protection period A small memory reserve for Type A Avoid competing with type C and paging Push memory pressure towards type C If there is no or very few type C pages Choose a loser and move it to type C MHERST Department of Computer Science 15
I/O scheduler: ongoing I/O priority / bandwidth Break FIFO waiting Type A task submit into request queue earlier Give it higher bandwidth Translate from scheduling spec Page swapping Tread swap in/out differently Treat kswapd differently MHERST Department of Computer Science 16
outline Motivation Redline: Specification CPU Scheduling Memory Manager I/O Scheduling Current Status MHERST Department of Computer Science 17
Current Status Finished Scheduler implementation Admission Control Integrated VMM Ongoing I/O Scheduler Load balancing MHERST Department of Computer Science 18
Experiment Results Vanilla-2.6.22.5 vs Redline 3Ghz, 1G mem, 2 G swap Scheduler overhead: 1, 2, 20, 200, and 2000 tasks ~1400 seconds, 30 times < 0.4% Mini load: one window, one movie Vanilla: video/audio stops when moving the window Redline: never miss a frame no matter how fast you move the window MHERST Department of Computer Science 19
Experiment Results Basic work load: movie, web browser, shell windows Type C fork bomb: 2000 tasks Type C malloc bomb: 4 x 300MB Type A fork bomb: 2000 tasks Type A malloc bomb: 4 x 300MB Launch all of them MHERST Department of Computer Science 20
Future work Load balancing Priority Inherent Dynamic Specification Adjustment Learning from history MHERST Department of Computer Science 21