On Mon, Sep 02, 2002 at 04:05:40PM +0200, Juergen Hannken-Illjes wrote:
> 
> The new strategy keeps disksort for write-requests while read-requests are
> put on a second queue with first-come first-serve strategy.
> Read-requests are served before write-requests.

There are some known pathological cases for absolute read-priority that
are, unfortunately, all too common.  SVR3 used this strategy, with poor
results overall, though it looks great in some microbenchmarks.  You can
find a capsule summary in Jeff Mogul's classic paper on smooth sync, I
believe, in the Usenix proceedings from '94 or thereabouts.

I think you would do better to use an algorithm like SGI's (I sent their
brief description of it to this list some time ago):  multiple queues, but
alternate between them: N from queue A, N from queue B, and so forth.  I 
also wonder whether SGI's choice to use sync/async rather than read/write as 
the discriminator between the queues might not be worth thinking about.

Finally, I wonder if it might make sense to attempt to merge adjacent
requests up to MAXPHYS at queue insert time.  Given fixed (and substantial!)
command overhead, simply reducing the number of I/O requests might help
more than one might think, particularly with request sources such as
RAIDframe that are known to produce smaller requests than the disks can
handle.

Good work, though!  Thanks very much!

Thor