[1488] in linux-scsi channel archive
Re: elevator sorting for the scsi subsystem.
daemon@ATHENA.MIT.EDU (Dario_Ballabio@milano.europe.dg.co)
Sun Mar 2 13:53:03 1997
Date: Sun, 2 Mar 1997 19:49:24 +0100
From: Dario_Ballabio@milano.europe.dg.com
To: linux-scsi@vger.rutgers.edu, lnz@dandelion.com
%UATTACH
>Cc: mingo@pc5829.hil.siemens.at
>In-Reply-To: <199702261551.QAA16087@milano.europe.dg.com>
>\011(Dario_Ballabio@milano.europe.dg.com)
> Date: Wed, 26 Feb 1997 16:51:59 +0100
> From: Dario_Ballabio@milano.europe.dg.com
>
> Actually there is no relation between my elevator sort implementation and
> any other portion of the kernel. I belive that some ideas in it could
> be used in a future remake of the mid level scsi layer.
> Actually before sorting I check wheter requests are already sorted
> and normally they are not.
> I just released the code to Linus and to the linux-kernel list, so you
> can see yourself how good/bad it is.
>
>According to previous discussions by Linus and others, the code in ll_rw_blk.c
>is more like a sawtooth than a pure elevator, and that's quite intentional. In
>my own experiments handing random access I/O requests to the SCSI layer
>directly, I've found that the best approach is to let the disk's own seek
>optimization algorithms work. On any modern SCSI disk that supports tagged
>queuing, the disk does as well or better at deciding the order of command
>execution. I think a future version of the block writing code should continue
>to coalesce adjacent requests, but should only elevator sort them if they are
>destined for a device that doesn't perform its own optimization.
>
>\011\011Leonard
>
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.
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).
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.
db
