Redline: Cooperative Scheduling of CPU, Memory and I/O

UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTSASSACHUSETTS, A, AMHERST MHERST •• Department of Computer ScienceDepartment of Computer Science

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*

UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTSASSACHUSETTS, A, AMHERST MHERST •• Department of Computer ScienceDepartment of Computer Science 2

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 …


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


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


Redline:

Effect:� Provide certain QoS to selected tasks� Ensure interactivity and responsiveness� Ensure controllability of the system� Provide better user experience when system is busy

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


outline

� Motivation

� Redline: Specification

� CPU Scheduling

� Memory Manager

� I/O Scheduling

� Current Status


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.


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#


outline

� Motivation


� CPU Scheduling

� Memory Manager

� I/O Scheduling

� Current Status


Existing SchedulersReal Time Scheduler

GPS Scheduler

EDF / RM

Knowledge, C/T

Strong assumption

Strict admission

Strong guarantee

Low throughput

TS / PS / FQ

No Knowledge, W

No assumption

No admission

No strict guarantee

High throughput

???EDF

+CFS


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


Example

0 5 10 15 20

P1: 3 / 8 : 1 P2: 2 / 4 : 1 P3: : 1

0 5 10 15 20


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


outline

� Motivation


� CPU Scheduling

� Memory Manager

� I/O Scheduling

� Current Status


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


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


outline

� Motivation


� CPU Scheduling

� Memory Manager

� I/O Scheduling

� Current Status


Current Status

� Finished

� Scheduler implementation

� Admission Control

� Integrated VMM

� Ongoing

� I/O Scheduler

� Load balancing


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


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


Future work

� Load balancing

� Priority Inherent

� Dynamic Specification Adjustment

� Learning from history

Documents

Redline: Cooperative Scheduling of CPU, Memory and I/O