I/O scheduler performance
Posted Aug 23, 2010 15:30 UTC (Mon) by epa
In reply to: A systemd status update
Parent article: A systemd status update
one thing we learned is that maximizing parallelization the way we do has little benefit on the disk elevator on rotating media. Naive people like me assumed that providing the current Linux IO scheduler with a larger amount of requests at the same time it can choose from would improve its performance. Turns out it currently doesn't really.
This is backed up by folk wisdom about how to get fast I/O on Unix-like systems. Do we run multiple cp commands in parallel to give the I/O scheduler more choice? When browsing a directory of image files, does the thumbnail viewer try to open them all simultaneously? We all know that this will tend to make things slower, not faster.
So has research in disk elevator algorithms reached the point where it's possible to do better - to throw large numbers of requests at the system and have it respond to them faster than it would if given one at a time? Or are we stuck (on rotating media at least) with the practical reality that most of the time, requests to the same disk are best made one at a time?
to post comments)