Rui's Blog
  • Rui's Blog/Paper Reading Notes - Introduction
  • Personal Blog
    • Personal Blog - Index
      • How to Create Picture-in-Picture Effect / Video Overlay for a Presentation Video
      • How to Do Your Part to Protect the Environment in Wisconsin
      • How to Get a Driver's License in Wisconsin
      • How to Travel from the U.S. to China onboard AA127 in June 2021
      • How to Transfer Credits Back to UW-Madison
      • Resources on Learning Academic Writing (for Computer Science)
    • Towards applying to CS Ph.D. programs
  • Machine Learning Systems
    • Machine Learning Systems - Index
      • MLSys Papers - Short Notes
      • [2011 NSDI] Dominant Resource Fairness: Fair Allocation of Multiple Resource Types
      • [2014 OSDI] Scaling Distributed Machine Learning with the Parameter Server
      • [2018 OSDI] Gandiva: Introspective Cluster Scheduling for Deep Learning
      • [2018 SIGCOMM] Chameleon: Scalable Adaptation of Video Analytics via Temporal and Cross-camera ...
      • [2018 NIPS] Dynamic Space-Time Scheduling for GPU Inference
      • [2019 ATC] Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads
      • [2019 NSDI] Tiresias: A GPU Cluster Manager for Distributed Deep Learning
      • [2019 SOSP] ByteScheduler: A Generic Communication Scheduler for Distributed DNN Training ...
      • [2019 SOSP] PipeDream: Generalized Pipeline Parallelism for DNN Training
      • [2019 SOSP] Parity Models: Erasure-Coded Resilience for Prediction Serving Systems
      • [2019 NIPS] GPipe: Efficient Training of Giant Neural Networks using Pipeline Parallelism
      • [2019 SC] ZeRO: memory optimizations toward training trillion parameter models
      • [2020 OSDI] Gavel: Heterogeneity-Aware Cluster Scheduling Policies for Deep Learning Workloads
      • [2020 OSDI] AntMan: Dynamic Scaling on GPU Clusters for Deep Learning
      • [2020 OSDI] BytePS: A High Performance and Generic Framework for Distributed DNN Training
      • [2020 SIGCOMM] Reducto: On-Camera Filtering for Resource-Efficient Real-Time Video Analytics
        • [2020 MLSys] Salus: Fine-Grained GPU Sharing Primitives for Deep Learning Applications
      • [2020 EuroSys] AlloX: Compute Allocation in Hybrid Clusters
      • [2020 VLDB] PyTorch Distributed: Experiences on Accelerating Data Parallel Training
      • [2020 NetAI] Is Network the Bottleneck of Distributed Training?
      • [2020 NSDI] Themis: Fair and Efficient GPU Cluster Scheduling
      • [2021 MLSys] Accordion: Adaptive Gradient Communication via Critical Learning Regime Identification
      • [2021 VLDB] Analyzing and Mitigating Data Stalls in DNN Training
      • [2021 FAST] CheckFreq: Frequent, Fine-Grained DNN Checkpointing
      • [2021 EuroMLSys] Interference-Aware Scheduling for Inference Serving
      • [2021 OSDI] Pollux: Co-adaptive Cluster Scheduling for Goodput-Optimized Deep Learning
      • [2021 MLSys] Wavelet: Efficient DNN Training with Tick-Tock Scheduling
      • [2021 NSDI] SwitchML: Scaling Distributed Machine Learning with In-Network Aggregation
    • Big Data Systems - Index
      • Big Data Systems Papers - Short Notes
      • [2003 SOSP] The Google File System
      • [2004 OSDI] MapReduce: Simplified Data Processing on Large Clusters
      • [2010 SIGMOD] Pregel: A System for Large-Scale Graph Processing
      • [2011 NSDI] Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center
      • [2012 NSDI] Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster ...
      • [2012 OSDI] PowerGraph: Distributed Graph-Parallel Computation on Natural Graphs
      • [2019 FAST] DistCache: Provable Load Balancing for Large-Scale Storage Systems with Distributed...
      • [2021 HotOS] From Cloud Computing to Sky Computing
      • [2021 EuroSys] NextDoor: Accelerating graph sampling for graph machine learning using GPUs
  • Earlier Readings & Notes
    • High Performance Computing Course Notes
      • Lecture 1: Course Overview
      • Lecture 2: From Code to Instructions. The FDX Cycle. Instruction Level Parallelism.
      • Lecture 3: Superscalar architectures. Measuring Computer Performance. Memory Aspects.
      • Lecture 4: The memory hierarchy. Caches.
      • Lecture 5: Caches, wrap up. Virtual Memory.
      • Lecture 6: The Walls to Sequential Computing. Moore’s Law.
      • Lecture 7: Parallel Computing. Flynn's Taxonomy. Amdahl's Law.
      • Lecture 8: GPU Computing Intro. The CUDA Programming Model. CUDA Execution Configuration.
      • Lecture 9: GPU Memory Spaces
      • Lecture 10: GPU Scheduling Issues.
      • Lecture 11: Execution Divergence. Control Flow in CUDA. CUDA Shared Memory Issues.
      • Lecture 12: Global Memory Access Patterns and Implications.
      • Lecture 13: Atomic operations in CUDA. GPU ode optimization rules of thumb.
      • Lecture 14: CUDA Case Studies. (1) 1D Stencil Operation. (2) Vector Reduction in CUDA.
      • Lecture 15: CUDA Case Studies. (3) Parallel Prefix Scan on the GPU. Using Multiple Streams in CUDA.
      • Lecture 16: Streams, and overlapping data copy with execution.
      • Lecture 17: GPU Computing: Advanced Features.
      • Lecture 18: GPU Computing with thrust and cub.
      • Lecture 19: Hardware aspects relevant in multi-core, shared memory parallel computing.
      • Lecture 20: Multi-core Parallel Computing with OpenMP. Parallel Regions.
      • Lecture 21: OpenMP Work Sharing.
      • Lecture 22: OpenMP Work Sharing
      • Lecture 23: OpenMP NUMA Aspects. Caching and OpenMP.
      • Lecture 24: Critical Thinking. Code Optimization Aspects.
      • Lecture 25: Computing with Supercomputers.
      • Lecture 26: MPI Parallel Programming General Introduction. Point-to-Point Communication.
      • Lecture 27: MPI Parallel Programming Point-to-Point communication: Blocking vs. Non-blocking sends.
      • Lecture 28: MPI Parallel Programming: MPI Collectives. Overview of topics covered in the class.
    • Cloud Computing Course Notes
      • 1.1 Introduction to Clouds, MapReduce
      • 1.2 Gossip, Membership, and Grids
      • 1.3 P2P Systems
      • 1.4 Key-Value Stores, Time, and Ordering
      • 1.5 Classical Distributed Algorithms
      • 4.1 Spark, Hortonworks, HDFS, CAP
      • 4.2 Large Scale Data Storage
    • Operating Systems Papers - Index
      • CS 736 @ UW-Madison Fall 2020 Reading List
      • All File Systems Are Not Created Equal: On the Complexity of Crafting Crash-Consistent Applications
      • ARC: A Self-Tuning, Low Overhead Replacement Cache
      • A File is Not a File: Understanding the I/O Behavior of Apple Desktop Applications
      • Biscuit: The benefits and costs of writing a POSIX kernel in a high-level language
      • Data Domain: Avoiding the Disk Bottleneck in the Data Domain Deduplication File System
      • Disco: Running Commodity Operating Systems on Scalable Multiprocessors
      • FFS: A Fast File System for UNIX
      • From WiscKey to Bourbon: A Learned Index for Log-Structured Merge Trees
      • LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation
      • LFS: The Design and Implementation of a Log-Structured File System
      • Lottery Scheduling: Flexible Proportional-Share Resource Management
      • Memory Resource Management in VMware ESX Server
      • Monotasks: Architecting for Performance Clarity in Data Analytics Frameworks
      • NFS: Sun's Network File System
      • OptFS: Optimistic Crash Consistency
      • RAID: A Case for Redundant Arrays of Inexpensive Disks
      • RDP: Row-Diagonal Parity for Double Disk Failure Correction
      • Resource Containers: A New Facility for Resource Management in Server Systems
      • ReVirt: Enabling Intrusion Analysis through Virtual-Machine Logging and Replay
      • Scheduler Activations: Effective Kernel Support for the User-Level Management of Parallelism
      • SnapMirror: File-System-Based Asynchronous Mirroring for Disaster Recovery
      • The Linux Scheduler: a Decade of Wasted Cores
      • The Unwritten Contract of Solid State Drives
      • Venti: A New Approach to Archival Storage
    • Earlier Notes
      • How to read a paper
  • FIXME
    • Template for Paper Reading Notes
Powered by GitBook
On this page
  • One-line Summary
  • Paper Structure Outline
  • Background & Motivation
  • Design and Implementation
  • Metric
  • Interface
  • Mechanism
  • Evaluation
  • New Vocabulary
  • Links

Was this helpful?

  1. Machine Learning Systems
  2. Machine Learning Systems - Index

[2020 NSDI] Themis: Fair and Efficient GPU Cluster Scheduling

One-line Summary

The authors present a new fairness metric, finish-time fairness, and a newer scheduler architecture and API that supports resource division according to the metric.

Paper Structure Outline

  1. Introduction

  2. Motivation

    1. Preliminaries

    2. Characterizing Production ML Apps

    3. Our Goal

  3. Finish-Time Fair Allocation

    1. Fair Sharing Concerns for ML Apps

      1. ML Task Durations

      2. Placement Preferences

    2. Metric: Finish-Time Fairness

    3. Mechanism: Partial Allocation Auctions

      1. One-Shot Auction

      2. Multi-round auctions

  4. System Design

    1. Design Requirements

    2. THEMIS Scheduler Architecture

      1. Need for a new scheduling architecture

      2. Two-Level Semi-Optimistic Scheduling

    3. AGENT and AppScheduler Interaction

      1. Single-Job ML Apps

      2. Generalizing to Multiple-Job ML Apps

      3. End-to-end Example

  5. Implementation

  6. Evaluation

    1. Experimental Setup

    2. Macrobenchmarks

      1. Sources of Improvement

      2. Effect of Contention

      3. Systems Overheads

    3. Microbenchmarks

    4. Sensitivity Analysis

  7. Related Work

  8. Conclusion

Background & Motivation

In large GPU clusters, existing scheduling disciplines do a poor job in fair sharing.

The authors presented the Sharing Incentive (SI): "If N deep learning apps are sharing a cluster, then no application should run slower than on a private cluster with 1/N resources". Similar fairness metrics include Pareto Efficiency (PE) and Envy-Freeness (EF).

Existing cluster scheduling frameworks are not adequate:

  1. Dominant Resource Fairness (DRF): The metric is "application resource share". It only uses instantaneous resource fairness (whenever resources are available, they are allocated to the task with the least current share). This is fine for big data analytics workloads, where task durations are short. For ML apps, though, running long, resource-intensive, gang-scheduled tasks might lead to newly-arrived jobs waiting, which is a violation of SI. Also, DRF does not take into account the placement preferences of ML apps. Modern ML apps have vastly different model architectures and placement preferences. For example, VGG16 is affected greatly by the hardware placement, while Inception-v3 is not. This is due to the difference in the amount of communication and synchronization for different workloads.

  2. Least Attained Service (LAS, Tiresias uses this): The metric is "app attained service, #GPUs * time". In Tiresias, GPUs are leased for a certain duration, and when leases expire, available GPUs are given to the job that received the least GPU time thus far. While this resolves the starvation issue mentioned above, it fails to address the placement issue: For two (sparse vs. dense) placements, Tiresias considers them to be the same as the attained service is equal, while actually, a poor placement leads to a slower execution time.

Design and Implementation

Metric

The authors presented the new metric finish-time fairness, ρ\rhoρ:ρ=Tsh/Tid\rho = T_{sh} / T_{id}ρ=Tsh​/Tid​

  • TshT_{sh}Tsh​: finish-time of app in shared cluster

  • TidT_{id}Tid​: finish-time of app in exclusive 1/N share of cluster

  • NNN: average contention during app lifetime

The SI requires that for every application, ρ≤1\rho \leq 1ρ≤1.

Interface

Hyperparameter Optimizers (Hyperparam-Opt, like Google Vizier) manage deep learning applications. The Hyperparam-Opt tracks per-job progress and determines which jobs to terminate early. Applications calculate ρ\rhoρ, and the scheduler pulls updated values of rho from the Agent co-located with the app's Hyperparam-Opt. For the CS 736 final, this is as deep as it will cover. In the future, I'll do a second read to try to dig deeper.

Mechanism

SI's focus is minimizing the max rho: min(max(rho))

Strawman Mechanism: When resources are available, the interface gets rho estimates from all apps, and then allocates the resources to the app with the highest rho for lease duration. There are two drawbacks (compared with Themis):

  1. May not find the most efficient allocation: It indeed allocates resources to the job that needs resources the most, but the job might not be the one that can utilize the resource the best.

  2. Cannot handle applications that lie about high rho values: Applications have the incentive to lie with high rho values to hoard GPU resources, which leads to starvations of honest jobs.

Themis introduces a knob, f, that manages a tradeoff between SI and efficiency.

  1. Solving inefficient allocation: When f = 0, more applications are allocated resources and, as a result, get better opportunities to match placement preferences of apps to resources. Analysis suggests f = 0.8 gives a good tradeoff.

  2. Incentivizing truth-telling of rho: Partial Allocation Auction within 1-f apps.

Evaluation

Baseline frameworks for comparison:

  • Tiresias: Least Attained Service Job First

  • Optimus: Best Throughput Scaling First

  • Gandiva: Best Packing Job First

  • SLAQ: Best Loss Gradient Job First

From Figure 9, we can observe a few things:

  1. Some apps perform very poorly with Tiresias due to placement inefficiency

  2. Themis is fair (rho <= 1.2)

  3. Themis is minimizing the max rho compared to other algorithms

From Figure 19, we can observe:

  1. In general, increasing f (filtering out more jobs) increases fairness and decreases max rho

  2. Increasing f gives us fewer scheduling choices, so it decreases GPU performance

  3. Short lease -> switch more rapidly between different jobs -> fairer

New Vocabulary

  • Hyperparameters: Data that govern the training process itself. Hyperparameters are set before the learning process begins. For example, the number of hidden layers, the number of nodes each layer should use, etc.

  • Hyperparameter tuning: The process of finding the best values of the hyperparameters.

Links

Previous[2020 NetAI] Is Network the Bottleneck of Distributed Training?Next[2021 MLSys] Accordion: Adaptive Gradient Communication via Critical Learning Regime Identification

Last updated 2 years ago

Was this helpful?

Preemptive and Non-Preemptive Scheduling
Paper PDF
Presentation Video at NSDI '20
Presentation Slides
An analysis of existing workloads
Different placement preferences of jobs
A violation of the SI due to the placement preferences being ignored
Calculating \rho for single-job ML apps
Strawman mechanism
The Themis approach
Partial Allocation Auction: Too detailed for CS 736, will cover in 2nd pass