[1489] in linux-scsi channel archive
Re: elevator sorting for the scsi subsystem.
daemon@ATHENA.MIT.EDU (Leonard N. Zubkoff)
Sun Mar 2 14:25:19 1997
Date: Sun, 2 Mar 1997 11:20:50 -0800
From: "Leonard N. Zubkoff" <lnz@dandelion.com>
To: Dario_Ballabio@milano.europe.dg.com
CC: linux-scsi@vger.rutgers.edu
In-reply-to: <199703021849.TAA18785@milano.europe.dg.com>
(Dario_Ballabio@milano.europe.dg.com)
Date: Sun, 2 Mar 1997 19:49:24 +0100
From: Dario_Ballabio@milano.europe.dg.com
The actual problem with ll_rw_blk.c is that it effectively always sorts in
ascending order (and the sawtooth doubles the seek distance compared to the
elevator sort), but only if the queue to the SCSI device is already filled up.
When there is still space on the queue to the SCSI device, requests are
released immediately and hence they are not sorted at all.
So we have the paradox that requests are likely to be sorted when the
device queue depth is small, but not sorted when the device queue depth is
large.
Actually, I think that what results in practice should work pretty well. If a
driver or device does not support tagged queuing, then generally the queue
depth is kept quite small, like 2 or 3. In that case, under load the queue
will usually be filled up, and the sorting code in ll_rw_blk.c will take
effect. If a driver and device do support tagged queuing, then the queue depth
will be set much larger (like 28), and a larger number of commands will be sent
to the disk where it can perform its own ordering optimizations.
The elevator sort implementation in the EATA driver sorts inside the
device queue depth and hence its performance increase proportionally to
the queue depth (the correct performance factor is Q/3, where Q is the
device queue depth).
This might well be because the EATA hardware does more than just pass on the
SCSI commands to the target devices, does it not? A large queue depth that
doesn't get passed on directly to the disks would be worse than sorting.
About the device optimization I do no know how safe is to rely on it for a
mix of read and write requests. We are eventually forced to use ordered
queue tags for write requests, loosing most of the gain possible with
a good elevator sorting implementation.
We will only need to use ordered queue tag requests at such time as the kernel
orders its writes. At the present time, there is no such ordering, so there's
no reason to use ordered queue tags, except to prevent command starvation. If
ordering were required, then drivers would not be allowed to elevator sort
requests except between write commands. I'm not sure what you are concerned
about with mixing of read and write accesses.
Leonard
