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 Disk Scheduler Basics Cello Architecture Cello Architecture Performance Characteristics Performance Characteristics Conclusions Conclusions

3. Disk Scheduler Basics

4. What is a Disk Scheduler? A part of the OS’s disk subsystem responsible to reordering disk requests to optimize disk access A part of the OS’s 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 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. Typically, a single disk scheduler manages one physical device, regardless of the number of logical partitions.

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

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

7. Seek-Reducing Policies FCFS – First Come First Served FCFS – First Come First Served –Only efficient for very light, low concurrency workloads SPTF – Shortest Positioning-Time First SPTF – Shortest Positioning-Time First –Optimizes overall disk throughput –Large worst-case response times (starvation) –Needs intimate knowledge of the physical device LOOK/SCAN 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 Time Slicing –Tradeoff between throughput and average response time –Not work-conserving EDF – Earliest Deadline First EDF – Earliest Deadline First –Poor throughput due to high positional latency –Good at servicing requests in order of importance FD-SCAN Feasible deadline scan 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 Real-time applications –Hard: require worst-case response time guarantees –Soft: require average response time guarantees Best-effort applications Best-effort applications –Interactive: require low average response times –Throughput-intensive: require overall system performance

10. Policy Suitability Real-time applications Real-time applications –Hard: EDF, etc. –Soft: FD-SCAN etc. Best-effort applications Best-effort applications –Interactive: SCAN, etc. –Throughput-intensive: SPTF, etc.

11. Similarities with Thread scheduling Performance requirements with respect to application classes Performance requirements with respect to application classes Coexistence – you must protect one application class from another Coexistence – you must protect one application class from another

12. Cello Architecture

13. Structure Hierarchy of queues Hierarchy of queues Requests move from one queue to another by a combined effort of the class-specific scheduler and the class-independent scheduler 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, w i, which is used to partition bandwidth A weight, w i, which is used to partition bandwidth A pending queue A pending queue A class-specific scheduler A class-specific scheduler

15. Class-Specific schedulers are responsible for: Ordering their pending queues. Ordering their pending queues. Placing requests of its class into the scheduled queue. 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. 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. Giving the class-specific schedulers information about the time requirements of requests in the scheduled queue.

17. The life-cycle of a Request 1. A new request is handed to the scheduler 2. Its class-specific scheduler, S i, places it in its pending queue, where it waits its turn 3. The class-independent scheduler, C, asks S i for a request 4. C gives the request back to the S i and asks it to place it in the scheduled queue 5. C tells S i whether it or not it rejects the placement 6. 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, w i Each application class is given a piece of the interval, P, proportional to its weight, w i C asks S i for additional requests until that application class’s allotment has filled C asks S i for additional requests until that application class’s allotment has filled Unused time is divided among classes with pending requests 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, w i In each interval, an application class is allowed to process an amount of data proportional to its weight, w i

20. Performance Characteristics

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

22. Response time Can be tuned as needed by the application class Can be tuned as needed by the application class Mixed request types are interleaved Mixed request types are interleaved Computational overhead is acceptable Computational overhead is acceptable

23. Conclusions

24. Questions/Concerns “The two-level framework cleanly separates class-independent mechanisms from class- specific scheduling policies” “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 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 (>80%) affect mixed use performance? –Wouldn’t using a 1000ms interval cause problems at high utilization?

25. A Step Back Good utilization Good utilization Mixed use response time is very good Mixed use response time is very good In the presence of homogeneous requests, the scheduling is optimal for that application class 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” Used in QLinux version 2.4.x, but is reportedly “not stable yet” Applications must classify themselves among the available classes: Applications must classify themselves among the available classes: –Interactive best effort –Throughput-intensive best effort –Real time