Parallel Job Scheduling Algorithms and Interfaces

1. Parallel Job SchedulingAlgorithms and Interfaces Research Exam for Cynthia Bailey Lee Department of Computer Science and Engineering University of California, San Diego May 27, 2004

2. Outline • Introduction • Problem Overview • Why does this matter? • Problem Specification • History • Early Approaches • Backfilling • Priorities • Evaluation • Metrics • Metric Pitfalls • User Perspectives • Future Directions

3. Running Jobs Queued Job Processors Processors Time Time Introduction: Problem OverviewWhy Does This Matter?Problem Specification What Are We Trying to Do? Job: System: Blue Horizon Message-Passing Parallel Scientific Code System Model: Job Model: Idle space CFD visualization: www.science-computing.de/products/powerviz.html

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

5. Introduction: Problem Overview Why Does This Matter? Problem Specification 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

6. History Outline • Introduction • Problem Overview • Why does this matter? • Problem Specification • History • Early Approaches • Backfilling • Priorities • Evaluation • Metrics • Metric Pitfalls • User Perspectives • Future Directions

7. History: Early Approaches Backfilling Priorities First Come First Serve(FCFS) Job 1 Processors Time Job 2 Job 3 Job 4 Queue:

8. History: Early Approaches Backfilling Priorities Tennis Court Scheduling[M93,P04] Job 1 Job 5 Job 2 Job 3 Job 4 Job 6 Processors Time Job 7

9. History: Early Approaches Backfilling Priorities EASY Backfilling[SCZL96] • 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]

10. 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]

11. History: Early ApproachesBackfilling Priorities Maui Scheduler [JS01] • Priorities—a function of 20+ parameters (don’t read this chart) • 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

12. History: Early ApproachesBackfilling Priorities Microeconomic Scheduler [SAWP95] A Unifying Principle Influence user behavior through accounting and charges, allow users to influence system behavior through payments [FR96] Job 1 Processors Time

13. Evaluation Outline • Introduction • Problem Overview • Why does this matter? • Problem Specification • History • Early Approaches • Backfilling • Priorities • Evaluation • Metrics • Metric Pitfalls • User Perspectives • Future Directions

14. Evaluation: Metrics Metric Pitfalls User Perspectives Common Metrics • Makespan • Utilization • ResponseTime • Expansion Factor (Slowdown) • Bounded Slowdown • Weighted Response Time

15. Evaluation: Metrics Metric Pitfalls User Perspectives Metric Pitfallsor “12 Ways to Fool the Masses When Giving Scheduler Performance Results” (Apologies to [B91]) • 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] • Use a workload that is unrealistic and shows off your scheduler’s strengths [MF01,FN95] • Avoid unpleasant related facts like internal fragmentation [PJN99] • Don’t waste time worrying about user-centric aspects of performance such as fairness and start-time guarantees [MF01] • Focus solely on performance, not user interface and implementation issues » Citations noted are exemplary cases of doing the right thing

16. u(t) Evaluation: MetricsMetric Pitfalls User Perspectives Scheduling in Context: User Utility Functions [FRSSW97] 8 am 12–1pm 5 pm-8 am 9 am

17. 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

18. 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)

19. Future Directions Empowering the User by Providing More Information[L04]

20. 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?

21. Conclusion Outline • Introduction • Problem Overview • Why does this matter? • Problem Specification • History • Early Approaches • Backfilling • Priorities • Evaluation • Metrics • Metric Pitfalls • User Perspectives • Future Directions