Historically, yes.
But we've been moving more and more towards a latency-based elevator, or
at least one that takes latency into account. Which is exactly why you'd
like to leave unfinished requests on the queue, because otherwise your
queue doesn't really show what is really going on.
In particular, while the higher layers don't actually _do_ this yet, from
a latency standpoint the right thing to do when some request seems to get
starved is to refuse to feed more tagged requeusts to the device until the
starved request has finished.
As I mentioned, Andrew actually had some really bad latency numbers to
prove that this is a real issue. SCSI with more than 4 tags or so results
in potentially _major_ starvation, because the disks themselves are not
even trying to avoid it.
Also, even aside from the starvation issue with unfair disks, just from a
"linear head movement" standpoint, you really want to sort the queue
according to what is going on _now_ in the disk. If the disk eats the
requests immediately (but doesn't execute them immediately), the sorting
has nothing to go on, and you get tons of back-and-forth movements.
Basically, if you're trying to do an elevator, you need to know what the
outstanding commands are. Think it through on paper, and you'll see what I
mean.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/