IOScheduling

This page is home to assorted disk I/O scheduling-related ideas that we might want to look at more closely in the future.

Two-layer Schedulers

Anticipation and CFQ's fairness logic don't work properly when applied to the queues on individual disks in a RAID set. The obvious approach to fixing this problem would be to do that part of the scheduling above the RAID layer, while leaving the merging and sorting in the lower layer. There are some implementation issues that would have to be overcome:

• The md and dm drivers pull requests off their incoming queue as soon as they arrive (and of course no scheduling is currently done on that queue). For AS/CFQ to do their thing, there needs to be either a way to tell the driver that certain requests should not yet be taken, or there needs to be yet another queue on which the schedulers act before passing the requests on to the driver's incoming queue.
• For CFQ to be effective, it needs to know how full the underlying queues are (anticipation aside, there's no point holding back I/Os if the device is idle).
• Anticipation should only happen if all the available requests would be issued to the same spindle as the one that is being anticipated. Otherwise you can keep issuing the requests that go to the other spindles.

Improved Fairness

Rather than using timeslices like CFQ, it may be worth implementing a scheduler that uses a token-bucket type scheme. Processes (or some other scheduling unit?) would have their requests accepted at varying rates depending on how much disk time they have used in the past. To do a proper job, the scheduler really needs to know when requests are completed, so it can keep track of how much time the disk actually spent servicing the request. Merging requests from different processes complicates the accounting a bit, perhaps a weighted average could be used? Also, if the scheduler is split as described above, this would mean that the lower scheduler needs to pass information back to the upper scheduler somehow.