DP-FAIR: A Simple Model for Understanding Optimal Multiprocessor Scheduling

Greg Levin† Shelby Funk‡ Caitlin Sadowski†

Ian Pye† Scott Brandt†

†University of California ‡University of GeorgiaSanta Cruz Athens

Backstory

NQ-Fairby Shelby Funk (Rejected from RTSS)

SNSby Greg, Caitlin,

Ian, and Scott (Rejected from RTSS)

DP-Fair

Multiprocessors

Most high-end computers today have multiple processors

In a busy computational environment, multiple processes compete for processor time More processors means more scheduling

complexity

4

Real-Time Multiprocessor Scheduling Real-time tasks have workload deadlines

Hard real-time = “Meet all deadlines!”

Problem: Scheduling periodic, hard real-time tasks on multiprocessor systems. This is difficult.

5

Real-Time Multiprocessor Scheduling

easy!!

Real-time tasks have workload deadlines

Hard real-time = “Meet all deadlines!”

Problem: Scheduling periodic, hard real-time tasks on multiprocessor systems. This is difficult.

Taxonomy of Multiprocessor Scheduling Algorithms

UniprocessorAlgorithms

LLFEDF

PartitionedAlgorithms

GlobalizedUniprocessor

Algorithms

GlobalEDF

DedicatedGlobal

Algorithms

PartitionedEDF

OptimalAlgorithms

EKG

LLREF

pfair

7

Partitioned Schedulers ≠ Optimal Example: 2 processors; 3 tasks, each with 2 units

of work required every 3 time units

8

Global Schedulers SucceedExample: 2 processors; 3 tasks, each with 2 units

of work required every 3 time units

Task 3 migrates between processors

9

Problem Model n tasks running on m processors

A periodic task T = (p, e) requires a workload e be completed within each period of length p

T's utilization u = e / p is the fraction of each period that the task must execute

job release

time = 0 p 2p 3p

job releasejob releasejob release

period p

workload e

time

workcompleted

job release deadline

Fluid Rate Curve

period p

workload e

fluid rate curveutilization u =slope = e/p

actual work curveslope = 0 or 1

10

job release deadline

Feasible Work Region

period p

workload e

zero

laxity

work completework

completed

time

11

CPU rate

= 1

12

Assumptions Processor Identity: All processors are equivalent

Task Independence: Tasks are independent

Task Unity: Tasks run on one processor at a time

Task Migration: Tasks may run on different processors at different times

No overhead: free context switches and migrations In practice: built into WCET estimates

13

The Big Goal (Version 1)

Design an optimal scheduling algorithm for periodic task sets on multiprocessors

A task set is feasible if there exists a schedule that meets all deadlines

A scheduling algorithm is optimal if it can

always schedule any feasible task set

14

Necessary and Sufficient Conditions Any set of tasks needing at most

1) 1 processor for each task ( for all i, ui ≤ 1 ) , and

2) m processors for all tasks ( ui ≤ m)

is feasible Proof: Small scheduling intervals can approximate a

task's fluid rate curve

Status: Solved pfair (1996) was the first optimal algorithm

15

The Big Goal (Version 2)

Design an optimal scheduling algorithm with fewer context switches and migrations ( Finding a feasible schedule with fewest

migrations is NP-Complete )

16

The Big Goal (Version 2)

Design an optimal scheduling algorithm with fewer context switches and migrations

Status: Solved BUT, the solutions are complex and confusing

Our Contributions: A simple, unifying theory for optimal global multiprocessor scheduling and a simple optimal algorithm

17

Greedy Algorithms Fail on Multiprocessors A Greedy Scheduling Algorithm will regularly

select the m “best” jobs and run those Earliest Deadline First (EDF) Least Laxity First (LLF)

EDF and LLF are optimal on a single processor ; neither is optimal on a multiprocessor Greedy approaches generally fail on multiprocessors

18

Example (n = 3 tasks, m = 2 processors) :

Why Greedy Algorithms FailOn Multiprocessors

19

Why Greedy Algorithms FailOn MultiprocessorsAt time t = 0, Tasks 1 and 2 are the obvious greedy choice

20

Why Greedy Algorithms FailOn MultiprocessorsEven at t = 8, Tasks 1 and 2 are the only “reasonable” greedy choice

21

Why Greedy Algorithms FailOn MultiprocessorsYet if Task 3 isn’t started by t = 8, the resultant idle time eventually causes a deadline miss

22

Why Greedy Algorithms FailOn Multiprocessors

How can we “see” this critical event at t = 8?

23

Proportioned AlgorithmsSucceed On Multiprocessors

Subdivide Task 3 with a period of 10

24

Proportioned AlgorithmsSucceed On Multiprocessors

Now Task 3 has a zero laxity event at time t = 8

25

Proportional Fairness

Insight: Scheduling is easier when all jobs have the same deadline

Application: Apply all deadlines to all jobs Assign workloads proportional to utilization Work complete matches fluid rate curve at

every system deadline

26

Proportional Fairness Is the Key

All known optimal algorithms enforce proportional fairness at all deadlines: pfair (1996) - Baruah, Cohen, Plaxton, and Varvel

( proportional fairness at all times )

BF (2003) - Zhu, Mossé, and Melhem LLREF (2006) - Cho, Ravindran, Jensen EKG (2006) - Andersson, Tovar

Why do they all use proportional fairness?

27

Scheduling Multiple Tasks is Complicated

time

workcompleted

28

Scheduling Multiple Tasks with Same Deadline is Easy

workcompleted

time

Actual Feasible Regions

29

workcompleted

time

job deadlines

Restricted Feasible Regions Under Deadline Partitioning

30

workcompleted

time

all system deadlines

31

The DP-Fair Scheduling Policy Partition time into slices based on all system deadlines

Allocate each job a per-slice workload equal to its utilization times the length of the slice

Schedule jobs within each slice in any way that obeys the following three rules:1. Always run a job with zero local laxity

2. Never run a job with no workload remaining in the slice

3. Do not voluntarily allow more idle processor time than

( m - ui ) x ( length of slice )

time

DP-Fair Work Allocation

time slice

Allocatedworkload

slope = utilization

32

workcompleted

DP-Fair Scheduling Rule #1

zero

local

laxity

line

When job hits zero local laxity, run to completion

33

time

workcompleted

time slice

DP-Fair Scheduling Rule #2

time slice

local workcomplete

line

When job finishes local workload, stop running

34

time

workcompleted

DP-Fair Scheduling Rule #3

time slice

Don’t voluntarily allow idle time in excess of this limit

slope = m - u i

slop

e =

m

Allowableidle time

35

time

idletime

36

DF-Fair Guarantees Optimality We say that a scheduling algorithm is

DP-Fair if it follows these three rules

Theorem: Any DP-Fair scheduling algorithm for periodic tasks is optimal

37

Proof of Theorem

38

DP-Fair Implications

( Partition time into slices ) + ( Assign proportional workloads )

Optimal scheduling is almost trivial

Minimally restrictive rules allow great latitude for algorithm design and adaptability

What is the simplest possible algorithm?

All time slices are equivalent (up to linear scaling), so normalize time slice length to 1 Jobs have workload = utilization

Schedule by “stacking and slicing” Line up job utilization blocks Slice at integer boundaries

39

The DP-Wrap Algorithm

40

The DP-Wrap Algorithm

Example: 3 processors, 7 tasks

41

The DP-Wrap Algorithm

Example: 3 processors, 7 tasks

42

The DP-Wrap Algorithm

Example: 3 processors, 7 tasks

43

The DP-Wrap Algorithm

44

DP-Wrap Performance

n−1 context switches and m−1 migrations per time slice

This is about 1/3 as many as LLREF, similar to BF, and somewhat more than EKG

DP-Wrap has very low (O(n)) computational complexity

45

Extending DP-Fair:Sporadic Arrivals, Arbitrary Deadlines

Sporadic arrivals: jobs from a task arrive at least p time units apart

Arbitrary deadlines: A job from T = (p, e, D) has a deadline D time units after arrival; D may be smaller or larger than p

DP-Fair and DP-Wrap are easily modified to handle these cases

46

DP-Fair Easily Extended

Extending optimal algorithms to sporadic tasks and arbitrary deadlines has previously been difficult pfair : 10 years LLREF : 3 years

DP-Fair & DP-Wrap: 3 weeks

Ongoing Work

Extend to uniform multiprocessors (CPUs running at different speeds)

Extend to random, unrelated job model Heuristic improvements to DP-Wrap

Work-conserving scheduling Slice merging

48

Summary

DP-Fair : Simple rules to make optimal real-time multiprocessor scheduling easy!!

DP-Wrap : Simplest known optimal multiprocessor scheduling algorithm

Extensible : DP-Fair and DP-Wrap easily handle sporadic tasks with arbitrary deadlines We plan to extend DP-Fair and DP-Wrap to more

general problem domains

49

Thanks for Listening Questions?

50

=== EXTRA SLIDES ===

1. Sporadic Tasks, Arbitrary Deadlines

51

Sporadic Arrivals, Arbitrary Deadlines We extend our task definition to Ti = (pi, ei, Di) ,

where each job of Ti has a deadline Di time units after its arrival; Di may be smaller or larger than pi. These are referred to as arbitrary deadlines.

Sporadic arrivals means that pi is now the minimum inter-arrival time for Ti's jobs, so that a new job will arrive at least pi time units after the previous arrival. Scheduling is on-line, i.e. we don't know ahead of time

when new jobs will arrive

52

Task Density

Our expression for utilization must be updated to the density of a task:

i = ei / min{ pi , Di } and are still

sufficient conditions for the feasibility of a task set, but they are no longer necessary. Example: T1 = (2, 1, 1) , T2 = (2, 1, 2) on m =

1 is feasible, although = 1.5.

53

Optimality Our updated DP-Fair rules for sporadic tasks with

arbitrary deadlines will allow an algorithm to schedule any task set with and

; in fact, we require that these conditions hold

Since feasible task sets exist where these conditions do not hold, DP-Fair algorithms are not optimal in this problem domain

This is an acceptable limitation, since it has recently been proven that no optimal scheduler can exist for sporadic tasks

54

Updated DP-Fair Scheduling

The rules for scheduling within time slices is nearly the same with sporadic tasks and arbitrary deadlines

The third rule is now:

"Do not voluntarily allow more than units of idle time to occur during the time slice before time t"

The Fj (t) term represents unused capacity between tasks' deadlines and next arrivals

55

Updated DP-Fair Allocation The rules for allocating workloads in time slices

become more complicated than simple proportionality

A task is active between its arrival and its deadline. When a task becomes active, it is allocated a workload proportional to its density and the length of its active segment in the slice

If a job arrives during a slice that will have a deadline within the slice, the remainder of the slice is partitioned into two new subslices, with a subslice boundary at the deadline, and remaining work for all tasks allocated proportionally to subslice lengths

Handling a Sporadic Arrival

time slice

Workloadallocatedupon arrival

Sporadic arrival in the middle of a slice

56

time

workcompleted

Managing Idle Time

time slice

Available idle time grows by utilization of unarrived sporadic job…

slope = m - u i

slop

e =

m

Original idle time pool

…until that job finally arrives

Additional idle time from late arrival

57

time

idletime

58

Theorem 3 Any DP-Fair scheduling algorithm for

sporadic tasks with arbitrary deadlines will successfully schedule any task set where

and

59

Modifying DP-Wrap

The DP-Wrap algorithm is easily modified to accommodate the DP-Fair scheduling rules for sporadic tasks with arbitrary deadlines

If a job arrives during a time slice, wrap it onto the end of the stack of blocks

If the arriving job has a deadline within the current slice, partition the remainder of the slice into two subslices, as per our previous rule, and apply the usual scheduling rules to both of these subslices