Which is the fairest I/O scheduler of them all?
Jens Axboe recently decided to do some more hacking on his "completely fair
queueing" (CFQ) scheduler; the result is the new time-sliced CFQ scheduler, which has since
seen a second third fourth revision. The CFQ scheduler has always
tried to divide the bandwidth of each block device fairly among the
processes performing I/O to that device; the time-sliced version goes
further by giving each process exclusive access to the device for a period
of time.
In particular, the time-sliced scheduler picks a process, and dispatches only that process's requests to the device for some tens of milliseconds. The device is allowed to go idle for a few milliseconds if all of the selected process's requests have been satisfied, with the idea that the process may generate more requests within that window. If those requests don't come, that process's time slice ends. Later revisions of the patch check to see whether the given process is actually likely to run within the idle window, and preempt the slice immediately if the answer is "no."
Jens claims some very good results for the new scheduler. The bandwidth numbers are nearly as good as those obtained with the anticipatory scheduler (AS), while the maximum latency is much less. These results may not be surprising; Jens has borrowed code from AS, and the idle window has a similar effect to the brief I/O stalls used by AS to improve read bandwidth. As the I/O schedulers poach the best ideas from each other, they may well become more alike. The use of time slices may also improve the locality of accesses to the drive, reducing the amount of time lost to seeks.
The new CFQ scheduler has spawned a low-key debate over which scheduler should be used by default. The default scheduler currently is AS, but some people (Andrea Arcangeli in particular) are saying that it should be CFQ instead. SUSE apparently already makes CFQ the default scheduler for its enterprise kernel. Andrew Morton is unsure; AS still seems to be better for desktop systems and IDE disks. Even so, he is ready to consider a change in the default scheduler:
The AS scheduler has already seen one improvement: a fix for a bug that
caused horrible performance for processes doing direct writes. Expect
other changes as AS hacker Nick Piggin works at improving its performance.
However this friendly competition turns out, better disk I/O performance
for Linux users will be part of it.
| Index entries for this article | |
|---|---|
| Kernel | Block layer/I/O scheduling |
| Kernel | CFQ I/O scheduler |
| Kernel | Elevator |
| Kernel | I/O scheduler |
Posted Dec 9, 2004 10:20 UTC (Thu)
by yusufg (guest, #407)
[Link] (1 responses)
Posted Dec 9, 2004 22:48 UTC (Thu)
by xorbe (guest, #3165)
[Link]
Posted Dec 16, 2004 10:08 UTC (Thu)
by philips (guest, #937)
[Link]
And later on users depending on their workloads can choose whatever they want.
But it is rather nice that Linux got two that good i/o schedulers ;)
Posted Dec 16, 2004 10:27 UTC (Thu)
by Milan (guest, #26716)
[Link]
Fedora Core also uses the CFQ as the default I/O schedulerWhich is the fairest I/O scheduler of them all?
I've always wanted my box to have a CFQ disk scheduler. The current high latency drives me up the wall. It's just silly. I don't even care if throughout drops somewhat, I want my box to *respond*.Which is the fairest I/O scheduler of them all?
Well, distro's could make simple applet to change i/o scheduler.Which is the fairest I/O scheduler of them all?
Current Beta2 of Red Hat Enterprise Linux has CFQ scheduler too so it seems to be more liked by vendors at this time.RHEL4