http://lwn.net/Articles/21274/?format=printableAnticipatory I/O schedulingIf an operating system is to perform well, it
must get top performance out
of its disk drives. The best use of disks is generally obtained by
recognizing a couple of basic facts of life:
Unfortunately, minimizing seeks and prioritizing reads can be somewhat contradictory goals. The way to keep seeks small and relatively rare is to maintain a sizeable backlog of requests; that way, nearby requests can be grouped and executed together. Getting the best performance on writes, in other words, requires delaying write operations for a period of time. If reads are to be handled quickly, however, they cannot be delayed and kept in the request queue in this way. It is even worse than that, actually. A process which is writing a file can have several outstanding write requests at any given time, since that process usually does not care when any particular request is completed. Processes issuing reads, on the other hand, usually generate them one at a time. The next read operation will not be requested until the previous one completes. So, even if delaying read operations were an acceptible thing to do, accumulating a backlog of close read operations is an unlikely proposition. The 2.4 kernel tends to mix reads in with the queue of write operations. Given the way things work (a read is not particularly likely to be close to an unrelated set of writes), reads tend to get put toward the end of the queue and executed slowly. That is one reason why 2.4 can be slow to respond when there is a lot of write activity going on. In the 2.5 kernel, reads are not allowed to languish long before they are pushed to the head of the queue and executed. This change can improve performance significantly, but it still does not solve the whole problem. As Andrew Morton put it in the 2.5.59-mm5 patch set: So far so good, but these fixes are still dumb.
Because we're solving the dependent read problem by creating a seek
storm. Every time someone submits a read, we stop writing, seek over
and service the read, and then *immediately* seek back and start
servicing writes again.
But in the common case, the application which submitted a read is about to go and submit another one, closeby on-disk to the first. So whoops, we have to seek back to service that one as well. As a result, overall performance suffers, since the disk is spending too much time seeking. 2.5.59-mm5 contains a new "anticipatory I/O scheduler" by Nick Piggin which attempts to address this problem. The basic idea is simple: if the drive has just handled a read request, assume that there is another one coming behind it and simply wait for a little bit. In this case, the request queue is plugged, the I/O scheduler sets a timer, and no more requests are passed down to the drive for a millisecond or so. If a "close" request shows up during the wait time, it is serviced right away; the distance that the kernel considers "close" grows as time passes. Eventually the close requests will stop coming, or the kernel will decide that it's time to get around to some writes regardless; at that point normal request dispatching resumes. Andrew reports a big improvement in performance (nearly a factor of six) over 2.5.59 for a simple test he was running. The code, it is said, still needs "quite some work," but it's a good start. 2.6 looks on track to be the most responsive Linux kernel yet.
Anticipatory I/O scheduling Posted Jan 30, 2003 8:26 UTC (Thu) by axboe (subscriber, #904) [Link] In all fairness, it isn't a entirely new io scheduler. In theory, you could add anticipation to any disk scheduler. It does not mean replacing everything that is there already.
Graceful admission Posted Jan 31, 2003 13:50 UTC (Fri) by paulsheer (guest, #3925) [Link] ...2.4 can be slow to respond......but these fixes are still dumb.... ...overall performance suffers... It's nice to see people finally admit that Linux does have a problem. **sigh of relief**
Graceful admission Posted Feb 1, 2003 10:31 UTC (Sat) by Peter (guest, #1127) [Link] It's nice to see people finally admit that Linux does have a problem. You must be new here. I don't remember anyone on the linux-kernel list (the source for much / most of the information on the lwn.net kernel pages) ever claiming Linux has no problems. Indeed, most people on that list are generally busy as can be fixing various problems. The only people who ever think any complex system is bug-free are the ignorant fanboys.
Graceful admission Posted Feb 5, 2003 15:24 UTC (Wed) by mwilck (guest, #1966) [Link] > The only people who ever think any complex system is bug-free are the> ignorant fanboys If you poke around in public forums (not as "elite" as lwn.net :-) you'll find mostly those, though. And they're not alone - there are the Linux "suits" as well, and some full-timers. It's one thing to discuss weaknesses in an internal developer forum like LKML and another thing to admit them in the public, knowing that admitting a problem may unleash an avalanche of bad press. Of course, this holds for
commercial Software companies to a much greater extent ... Microsoft
doesn't exactly have a reputation for openly discussing its software's
weaknesses, either.
|
