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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
