Cello

1
Cello

• A Disk Scheduling Framework for Next Generation
  Operating Systems Prashant J. Shenoy and
  Harrick M. Vin

Presented by Evan Clark September 8, 2003
2
Contents

• Disk Scheduler Basics
• Cello Architecture
• Performance Characteristics
• Conclusions

3
Disk Scheduler Basics
4
What is a Disk Scheduler?

• A part of the OSs disk subsystem responsible to
  reordering disk requests to optimize disk access
• Architecturally, a disk scheduler is either part
  of the file system, or it sits above it
• Typically, a single disk scheduler manages one
  physical device, regardless of the number of
  logical partitions.

5
Disk Performance

• Transfer rate
• Positional performance
• Head Seek Time
• Rotational Latency
• Performance is a function of where the head is
  and where the data resides
• Access time measured in milliseconds

6
Scheduling Policies

• Seek-Reducing Policies
• Good overall throughput
• Deadline-Oriented Scheduling policies
• Can provide response-time guarantees

7
Seek-Reducing Policies

• FCFS First Come First Served
• Only efficient for very light, low concurrency
  workloads
• SPTF Shortest Positioning-Time First
• Optimizes overall disk throughput
• Large worst-case response times (starvation)
• Needs intimate knowledge of the physical device
• LOOK/SCAN
• Disk head traverses only in one direction
• Good throughput
• Avoids starvation
• Large worst-case response times

8
Deadline-Oriented Scheduling policies

• Time Slicing
• Tradeoff between throughput and average response
  time
• Not work-conserving
• EDF Earliest Deadline First
• Poor throughput due to high positional latency
• Good at servicing requests in order of importance
• FD-SCAN Feasible deadline scan
• Scan in the direction of the request with the
  next deadline
• Good statistical performance

9
Application Classes

• Real-time applications
• Hard require worst-case response time guarantees
• Soft require average response time guarantees
• Best-effort applications
• Interactive require low average response times
• Throughput-intensive require overall system
  performance

10
Policy Suitability

• Real-time applications
• Hard EDF, etc.
• Soft FD-SCAN etc.
• Best-effort applications
• Interactive SCAN, etc.
• Throughput-intensive SPTF, etc.

11
Similarities with Thread scheduling

• Performance requirements with respect to
  application classes
• Coexistence you must protect one application
  class from another

12
Cello Architecture
13
Structure

• Hierarchy of queues
• Requests move from one queue to another by a
  combined effort of the class-specific scheduler
  and the class-independent scheduler

14
Each Application Class has

• A weight, wi, which is used to partition
  bandwidth
• A pending queue
• A class-specific scheduler

15
Class-Specific schedulers are responsible for

• Ordering their pending queues.
• Placing requests of its class into the scheduled
  queue.

16
Class-Independent schedulers are responsible for

• Regulating the entry of requests into the
  scheduled queue.
• Giving the class-specific schedulers information
  about the time requirements of requests in the
  scheduled queue.

17
The life-cycle of a Request

• A new request is handed to the scheduler
• Its class-specific scheduler, Si, places it in
  its pending queue, where it waits its turn
• The class-independent scheduler, C, asks Si for
  a request
• C gives the request back to the Si and asks it to
  place it in the scheduled queue
• C tells Si whether it or not it rejects the
  placement
• Once the scheduled queue is as full as it will
  get, each request is sent to the file system in
  order

18
Proportionate Time- Allocation

• Each application class is given a piece of the
  interval, P, proportional to its weight, wi
• C asks Si for additional requests until that
  application classs allotment has filled
• Unused time is divided among classes with pending
  requests

19
Proportionate Byte-Allocation

• In each interval, an application class is allowed
  to process an amount of data proportional to its
  weight, wi

20
Performance Characteristics
21
Utilization

• Very good
• Cello is a work-conserving scheduler
• Periodic requests are handled at whatever
  frequency is defined by the application
• Best-effort requests fill in the gaps left by
  periodic requests

22
Response time

• Can be tuned as needed by the application class
• Mixed request types are interleaved
• Computational overhead is acceptable

23
Conclusions
24
Questions/Concerns

• The two-level framework cleanly separates
  class-independent mechanisms from class-specific
  scheduling policies
• Deceptive idleness a phenomenon in
  work-conserving schedulers in which a requester
  is assumed to be idle because it has no requests
  pending at decision points
• How does high utilization (gt80) affect mixed use
  performance?
• Wouldnt using a 1000ms interval cause problems
  at high utilization?

25
A Step Back

• Good utilization
• Mixed use response time is very good
• In the presence of homogeneous requests, the
  scheduling is optimal for that application class
• Used in QLinux version 2.4.x, but is reportedly
  not stable yet
• Applications must classify themselves among the
  available classes
• Interactive best effort
• Throughput-intensive best effort
• Real time