parallel job scheduling algorithms and interfaces research exam for cynthia bailey lee department of...

Parallel Job SchedulingAlgorithms and Interfaces

Research Exam for

Cynthia Bailey Lee

Department of Computer Science and Engineering

University of California, San DiegoMay 27, 2004

Outline

• Introduction– Problem Overview– Why does this matter? – Problem Specification

• History– Early Approaches– Backfilling– Priorities

• Evaluation– Metrics– Metric Pitfalls– User Perspectives

• Future Directions

What Are We Trying to Do?

Introduction: Problem Overview Why Does This Matter? Problem Specification

Job:

BlueHorizon

CFD visualization: www.science-computing.de/products/powerviz.html

System:

Job Model: System Model:

Time

Pro

cesso

rs

Time

Pro

cesso

rs Running Jobs

Queued Job

Message-PassingParallel Scientific Code

Idle space

Why Does This Matter?

Introduction: Problem Overview Why Does This Matter? Problem Specification

0

50

100

150

200

250

300

350

400

19

93

19

93

19

94

19

94

19

95

19

95

19

96

19

96

19

97

19

97

19

98

19

98

19

99

19

99

20

00

20

00

20

01

20

01

20

02

20

02

20

03

20

03

Nu

mb

er

of

Syst

em

s in

Top

50

0

Time- sharingSpace- sharingOther

Systems in the Top500 typically range in price from $1 million to $50 million+

Top500 data: www.top500.org

Problem Specification

• Purpose process a workload parallel batch jobs

• Processor Homogeneity machine consists of N identical processors

• Job Specification processors by requested runtime

• Exclusivity jobs do not share processors

• Non-Preemption once begun, jobs run to completion

• Online jobs arrive stochastically, no knowledge of future

• Accounting there is a scheme to track users' resource consumption

• User Independence users are in competition for system resources

Introduction: Problem Overview Why Does This Matter? Problem Specification

Outline

• Introduction– Problem Overview– Why does this matter?– Problem Specification

• History– Early Approaches– Backfilling– Priorities

• Evaluation– Metrics– Metric Pitfalls– User Perspectives

• Future Directions

History

First Come First Serve(FCFS)

Job 1

Job 4Job 3

Time

Pro

cesso

rs

Job 2

History: Early Approaches Backfilling Priorities

Queue:

Tennis Court Scheduling[M93,P04]

Job 2

Job 3 Job 4

Job 7

Job 6

Time

Pro

cesso

rs

Job 1Job 5

History: Early Approaches Backfilling Priorities

• Allow backfills when the projected start of first job in the queue is not delayed

• No starvation—all jobs will eventually run• Claim: “Jobs in the queue are never delayed

from running by jobs submitted to the queue after them.”

• Disproved [MF01]

EASY Backfilling[SCZL96]

History: Early Approaches Backfilling Priorities

Conservative Backfilling• Allow backfills when the projected starts of all

preceding jobs in the queue are not delayed• Worst-case start time guaranteed at submittal• Claim: “guarantees that future arrivals do not

delay previously queued jobs.” [MF01]• Disproved—depending on semantics of “delay”

[JSC01]

History: Early Approaches Backfilling Priorities

Maui Scheduler [JS01]

• Priorities—a function of 20+ parameters (don’t read this chart)

History: Early Approaches Backfilling Priorities

• Parameterized backfills– Backfilling allowed when the projected starts of the N preceding jobs in the queue are not delayed

Maui is deployed on many major systems

Microeconomic Scheduler [SAWP95]

A Unifying PrincipleInfluence user behavior through accounting

and charges, allow users to influence system behavior through payments [FR96]

Job 1

Time

Pro

cesso

rs

History: Early Approaches Backfilling Priorities

Outline

• Introduction– Problem Overview– Why does this matter?– Problem Specification

• History– Early Approaches– Backfilling– Priorities

• Evaluation– Metrics– Metric Pitfalls– User Perspectives

• Future Directions

Evaluation

Common Metrics

• Makespan • Utilization• ResponseTime • Expansion Factor (Slowdown)• Bounded Slowdown • Weighted Response Time

Evaluation: Metrics Metric Pitfalls User Perspectives

Metric Pitfallsor “12 Ways to Fool the Masses When Giving Scheduler Performance Results” (Apologies to [B91])

1. Rely on a single number (e.g. average)• Don’t mention what happens to the unluckiest jobs

[CADV02]—especially avoid focusing on those hard-to-schedule big jobs [SKSS02, EHY02]

2. Use a workload that is unrealistic and shows off your scheduler’s strengths [MF01,FN95]

3. Avoid unpleasant related facts like internal fragmentation [PJN99]

4. Don’t waste time worrying about user-centric aspects of performance such as fairness and start-time guarantees [MF01]

5. Focus solely on performance, not user interface and implementation issues

Evaluation: Metrics Metric Pitfalls User Perspectives

» Citations noted are exemplary cases of doing the right thing

8 am 12–1pm 5 pm-8 am 9 am

Scheduling in Context: User Utility Functions

[FRSSW97]

Evaluation: Metrics Metric Pitfalls User Perspectives

u(t

)

Outline

• Introduction– Problem Overview– Why does this matter?– Problem Specification

• History– Early Approaches– Backfilling– Priorities

• Evaluation– Metrics– Metric Pitfalls– User Perspectives

• Future Directions

Future Directions

Scheduling Explicitly by User Utility Function

[L04, FrN95]

• If user utility functions can be collected, a scheduler can be designed to explicitly optimize the global utility– A survey of users at SDSC demonstrated

feasibility of collection for crude utility functions

• Formulated as a Linear program—with some integer constraints—finding the optimal solution is NP-hard– Commercially available solvers are able to

produce good solutions in reasonable timeframes (< 1 minute)

Future Directions

Empowering the User by Providing More

Information[L04]

Future Directions

User-Provided Inputs[MF01, LSHS04]

• Users are strongly motivated to overestimate in their requested runtimes– Jobs are killed when the time expires

• Can users be more accurate when not threatened with death, and with more tangible rewards?

Future Directions

Outline

• Introduction– Problem Overview– Why does this matter?– Problem Specification

• History– Early Approaches– Backfilling– Priorities

• Evaluation– Metrics– Metric Pitfalls– User Perspectives

• Future Directions

Conclusion