[1492] in linux-scsi channel archive
Re: elevator sorting for the scsi subsystem.
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Sun Mar 2 16:14:53 1997
Date: Sun, 2 Mar 1997 22:10:49 +0000 (GMT)
From: Gerard Roudier <groudier@club-internet.fr>
To: Dario_Ballabio@milano.europe.dg.com
cc: linux-scsi@vger.rutgers.edu, lnz@dandelion.com
In-Reply-To: <199703021849.TAA18785@milano.europe.dg.com>
On Sun, 2 Mar 1997 Dario_Ballabio@milano.europe.dg.com wrote:
> %UATTACH
> 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.
First, I think that there is no reason to use ordered queue tag if the
kernel and disk firmwares act correctly.
Then, unless I am very tired, a performance factor of Q/3 has no sense
for me. I need to know what 'performance' and 'factor' mean in this
context and what I must calculate with such values.
My opinion about disk IO optimization algorithms is that the right
places for them are:
1. As close as possible to the application program.
2. As close as possible to the physical components of disks.
(1) makes very complex applications and so, the kernel is a better
candidate for optimization algorithm like command reordering/sorting,
IO clustering, (asynchronous) read ahead etc...
However, doing such optimization at application level in some
rare cases must not be excluded.
(2) the disk firmware is obviously the right place for optimization
since all physical parameter can be known by it at any time.
So, any optimization that is done in another place in the scsi layers
is just "crystal ball based", in my opinion, and is worse than nothing
each time it increase latency.
I think that the real vertue of the couple driver+HBA are:
1. Allow upper layers (scsi drivers) to use all available scsi features
and disks features.
2. Have very low latency.
If kernel algorithms are not good enough, we must (try to) improve them.
Any sort algorithm in a low-level driver that increase performance,
only prooves that there is room for improvement in the kernel.
In my opinion, that's the same with assumed intelligent controllers.
Such layers of the scsi subsystem act as a prosthesis for silly
kernels and/or hard disk firmwares when they are able to increase
performances.
Gerard.
