Parallel Job Scheduling Algorithms and Interfaces Research Exam for Cynthia Bailey Lee Department of Computer Science and Engineering University of California, San Diego May 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: Blue Horizon CFD visualization: System: Job Model: System Model: Time Processors Time Processors Running Jobs Queued Job Message-Passing Parallel Scientific Code Idle space

Why Does This Matter? Introduction: Problem Overview Why Does This Matter? Problem Specification Systems in the Top500 typically range in price from $1 million to $50 million+ Top500 data:

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 4 Job 3 Time Processors Job 2 History: Early Approaches Backfilling Priorities Queue:

Tennis Court Scheduling [M93,P04] Job 2 Job 3Job 4 Job 7 Job 6 Time Processors Job 1 Job 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 Principle Influence user behavior through accounting and charges, allow users to influence system behavior through payments [FR96] Job 1 Time Processors 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 Pitfalls or “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

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