M. Edward (Ed) Borasky wrote:
> At the CMG meeting I asked the disk drive engineers, "well, if the
> drives are doing the scheduling, why does Linux go to all the trouble?"
One big reason is that Linux knows more about the relative importance of
I/O operations than the individual drives do. Linux's scheduler supports
priorities in its queuing, and is able to do things like try to perform
small blocking reads before long non-blocking writes in order to improve
overall system throughput.
The individual drives just don't have the knowledge to make these
decisions. All they can really do is try to fetch the set of blocks
currently requested in the smallest possible time. This can even be
harmful if, in order to improve overall throughput, the drive reorders
what to the OS is a very high priority operation and performs it later
than it would've if following the request queue directly.
I've had to modify the 3ware driver to set very shallow request queues
for similar reasons. It was using very deep queuing and the controller
seems to do very stupid request queuing where it maintains a single deep
per-controller queue rather than per-array queues, so I was getting
AWFUL request latencies on high priority small reads when bulk I/O was
in progress elsewhere - even on another array on the same controller.
I've also had to turn NCQ off on SATA disks before because it was
foiling Linux's I/O priority management, so tasks with low ionice levels
still ended up rather severely impacting system responsiveness.
Hopefully these devices will end up with the smarts to manage I/O in a
priority queue where read latency is considered as well as throughput.
> Their answer was something like, "smart disk drives are a relatively
> recent invention." But
--
Craig Ringer
