Download presentation
Presentation is loading. Please wait.
1
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
2
Outline Introduction History Evaluation Future Directions
Problem Overview Why does this matter? Problem Specification History Early Approaches Backfilling Priorities Evaluation Metrics Metric Pitfalls User Perspectives Future Directions
3
What Are We Trying to Do? Job: System: System Model: Job Model:
Introduction: Problem Overview Why 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 Time Processors Running Jobs Queued Job Time Processors CFD visualization:
4
Introduction: Problem Overview Why Does This Matter
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:
5
Problem Specification
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
Outline Introduction History Evaluation Future Directions
Problem Overview Why does this matter? Problem Specification History Early Approaches Backfilling Priorities Evaluation Metrics Metric Pitfalls User Perspectives Future Directions
7
First Come First Serve (FCFS)
History: Early Approaches Backfilling Priorities First Come First Serve (FCFS) Job 1 Processors Time Job 2 Job 3 Job 4 Queue:
8
Tennis Court Scheduling [M93,P04]
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
![Tennis Court Scheduling [M93,P04]](http://slideplayer.com/slide/12859982/78/images/8/Tennis+Court+Scheduling+%5BM93%2CP04%5D.jpg "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
EASY Backfilling [SCZL96]
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]
![EASY Backfilling [SCZL96]](http://slideplayer.com/slide/12859982/78/images/9/EASY+Backfilling+%5BSCZL96%5D.jpg "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
Conservative Backfilling
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
Maui Scheduler [JS01] < Maui is deployed on many major systems
History: Early Approaches Backfilling 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
![Maui Scheduler [JS01] < Maui is deployed on many major systems](http://slideplayer.com/slide/12859982/78/images/11/Maui+Scheduler+%5BJS01%5D+%3C+Maui+is+deployed+on+many+major+systems.jpg "History: Early Approaches Backfilling 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
Microeconomic Scheduler [SAWP95]
History: Early Approaches Backfilling 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
![Microeconomic Scheduler [SAWP95]](http://slideplayer.com/slide/12859982/78/images/12/Microeconomic+Scheduler+%5BSAWP95%5D.jpg "History: Early Approaches Backfilling 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
Outline Introduction History Evaluation Future Directions
Problem Overview Why does this matter? Problem Specification History Early Approaches Backfilling Priorities Evaluation Metrics Metric Pitfalls User Perspectives Future Directions
14
Common Metrics Makespan Utilization ResponseTime
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 Pitfalls or “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
Scheduling in Context: User Utility Functions [FRSSW97]
Evaluation: Metrics Metric Pitfalls User Perspectives Scheduling in Context: User Utility Functions [FRSSW97] u(t) Assume that a job i needs approximately 3 hours of computation time. If the user submits the job in the morning (9am) he may expect to receive the results after lunch. It probably does not matter to him whether the job is started immediately or delayed for an hour as long as it is done by 1pm. Any delay beyond 1pm may cause annoyance and thus reduce user satisfaction, i.e. increase costs. This corresponds to tardiness scheduling. However, if the job is not completed before 5pm it may be sufficient if the user gets his results early next morning. Moreover, he may be able to deal with the situation easily if he is informed at the time of submittal that execution of the job by 5pm cannot be expected. Also, if the user is charged for the use of system resources, he may be willing to postpone execution of his job until nighttime when the charge is reduced. [FRSSW97] 8 am –1pm pm-8 am am
![Scheduling in Context: User Utility Functions [FRSSW97]](http://slideplayer.com/slide/12859982/78/images/16/Scheduling+in+Context%3A+User+Utility+Functions+%5BFRSSW97%5D.jpg "Evaluation: Metrics Metric Pitfalls User Perspectives. Scheduling in Context: User Utility Functions [FRSSW97] u(t) Assume that a job i needs approximately 3 hours of computation time. If the user submits the job in the morning (9am) he may expect to receive the results after lunch. It probably does not matter to him whether the job is started immediately or delayed for an hour as long as it is done by 1pm. Any delay beyond 1pm may cause annoyance and thus reduce user satisfaction, i.e. increase costs. This corresponds to tardiness scheduling. However, if the job is not completed before 5pm it may be sufficient if the user gets his results early next morning. Moreover, he may be able to deal with the situation easily if he is informed at the time of submittal that execution of the job by 5pm cannot be expected. Also, if the user is charged for the use of system resources, he may be willing to postpone execution of his job until nighttime when the charge is reduced. [FRSSW97] 8 am 12–1pm 5 pm-8 am 9 am.")
17
Outline Introduction History Evaluation Future Directions
Problem Overview Why does this matter? Problem Specification History Early Approaches Backfilling Priorities Evaluation Metrics Metric Pitfalls User Perspectives Future Directions
18
Scheduling Explicitly by User Utility Function [L04, FrN95]
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)
![Scheduling Explicitly by User Utility Function [L04, FrN95]](http://slideplayer.com/slide/12859982/78/images/18/Scheduling+Explicitly+by+User+Utility+Function+%5BL04%2C+FrN95%5D.jpg "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
Empowering the User by Providing More Information [L04]
Future Directions Empowering the User by Providing More Information [L04]
![Empowering the User by Providing More Information [L04]](http://slideplayer.com/slide/12859982/78/images/19/Empowering+the+User+by+Providing+More+Information+%5BL04%5D.jpg "Future Directions. Empowering the User by Providing More Information [L04]")
20
User-Provided Inputs [MF01, LSHS04]
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?
![User-Provided Inputs [MF01, LSHS04]](http://slideplayer.com/slide/12859982/78/images/20/User-Provided+Inputs+%5BMF01%2C+LSHS04%5D.jpg "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
Outline Introduction History Evaluation Future Directions
Conclusion Outline Introduction Problem Overview Why does this matter? Problem Specification History Early Approaches Backfilling Priorities Evaluation Metrics Metric Pitfalls User Perspectives Future Directions
Similar presentations
