Disk Scheduling In Linux

1. Disk Scheduling In Linux It’s really quite complex!

2. My Goals • Teach a little bit of Computer Science. • Show that the easy stuff is hard in real life. • BTW, Operating systems are cool!

3. How A Disk Works • A disk is a bunch of data blocks. • A disk has a disk head. • Data can only be accessed when the head is on that block. • Moving the head takes FOREVER. • Data transfer is fast (once the disk head gets there).

4. The Problem Statement • Suppose we have multiple requests for disk blocks …. Which should we access first?P.S. Yes, order does matter … a lot.

5. Formal Problem Statement • Input: A set of requests. • Input: The current disk head location. • Input: Algorithm state (direction??) • Output: The next disk block to get.P.S. Not the whole ordering, just the next one.

6. The Goals • Maximize throughput • Operations per second. • Maximize fairness • Whatever that means. • Avoid Starvation • And very very long waits. • Real Time Concerns • These can be life threatening (and bank accounts too!).

7. What’s Not Done • Every Operating system assigns priorities to all sorts of things • Requests for RAM • Requests for the CPU • Requests for network access • Few use disk request priority.

8. Why Talk About This Now? • Because in the last year Linux has had three very different schedulers, and they’ve been tested against each other.

9. A Pessimal Algorithm • Choose the disk request furthest from the current disk head. • This is known to be as bad as any algorithm without idle periods.

10. An Optimal Algorithm • Chose the disk request closest to the disk head. • It’s Optimal!

11. Optimal Analyzed • This is known to have the highest performance in operations per second. • It’s unfair to requests toward the edges of the disk. • It allows for starvation.

12. First Come First Serve • Serve the requests in their arrival order. • It’s fair. • It avoid starvation. • It’s medium lousy performance. • Some simple OSs use this.

13. Elevator • Move back and forth, solving requests as you go. • Performance • good • Fairness • Files near the middle of the disk get 2x the attention.

14. Cyclic Elevator • Move toward the bottom, solving requests as you go. • When you’ve solved the lowest request, seek all the way to the highest request. • Performance penalty occurs here.

15. Cyclic Elevator Analyzed • It’s fair. • It’s starvation-proof. • It’s very good performance. • Almost as good as elevator. • It’s used in real life (and every textbook).

16. Each request has a deadline. Service requests using cyclic elevator. When a deadline is threatened, skip directly to that request. For Real Time (which means xmms) Jens Axboe Deadline Scheduler

17. Deadline Analyzed • Gives Priority to Real Time Processes. • Fair otherwise. • No starvation • Unless a real time process goes wild.

18. Anticipatory Scheduling(The Idea) • Developed by several people. • Coded by Nick Piggin. • Assume that an I/O request will be closely followed by another nearby one.

19. Anticipatory Scheduling(The Algorithm) • After servicing a request … WAIT. • Yes, this means do nothing even though there is work to be done. • If a nearby request occurs soon, service it. • If not … cyclic elevator.

20. Anticiptory Scheduling Analyzed • Fair • No support for real time. • No starvation. • Makes assumptions about how processes work in real life. • That’s the idleness. • They better be right

21. Benchmarking the Anticipatory Scheduler Source: http://www.cs.rice.edu/~ssiyer/r/antsched/antsched.pdf

22. Completely Fair Queuing(also by Jens) • Real Time needs always come first • Otherwise, no user should be able to hog the disk drive. • Priorities are OK.

23. The CFQ Picture RT 10ms Valve Disk Queue Dispatcher Q1 Q2 Disk Q20 Yes, Gabe’s art is better

24. Analyzing CFQ • Complex!!!!! • Has Real Time support (Jens likes that). • Fair, and fights disk hogs! • A new kind of fairness!! • No starvation is possible. • Real time crazyness excepted. • Allows for priorities • But no one knows how to assign them.

25. Benchmark #1 • time (find kernel-tree -type f | xargs cat > /dev/null) Dead: 3 minutes 39 secondsCFQ: 5 minutes 7 secondsAS: 17 seconds

26. The Benchmark #2 for i in 1 2 3 4 5 6dotime (find kernel-tree-$i -type f | xargs cat > /dev/null ) & done Dead: 3m56.791s CFQ: 5m50.233s AS: 0m53.087s

27. The Benchmark #3 time (cp 1-gig-file foo ; sync) AS: 1:22.36CFQ: 1:25.54Dead: 1:11.03

28. Benchmark #4 • time ssh testbox xterm -e true Old: 62 secondsDead: 14 secondsCFQ: 11 secondsAS: 12 seconds

29. Benchmark #5 • While “cat 512M-file > /dev/null “ • Measure “write-and-fsync -f -m 100 outfile” Old: 6.4 secondsDead: 7.7 secondsCFQ: 8.4 secondsAS: 11.9 seconds

30. The Winner is … • Andrew Morton said, "the anticipatory scheduler is wiping the others off the map, and 2.4 is a disaster."

31. What You Learned • In Real Operating Systems … • Performance is never obvious. • No one uses the textbook algorithm. • Benchmarking is everything. • Theory is useful, if it helps you benchmark better. • Linux is cool, since we can see the development process.