On Mon, Sep 02, 2002 at 07:39:56PM +0200, Juergen Hannken-Illjes wrote:
> On Mon, Sep 02, 2002 at 01:32:35PM -0400, Thor Lancelot Simon wrote:
> 
> It's not absolute, after 48 continues read's with a non-empty write-queue,
> the write-queue drains for 16 requests. I triggered this condition less
> then 5 times during my tests.

This sounds similar to SGI's algorithm, but not _quite_ the same.  In
their case, they alternate back and forth between the two queues, with
a maximum number of requests to be taken from each queue that is adjusted
at run time.  How did you choose 48 and 16?  The asymmetry would seem
guaranteed to bias the system in favor of reads, which could have unexpected
effects with some workloads.  I believe they also have an additional rule:
two requests that are physically adjacent count as one request, which should
have an impact similar to, though not quite the same as, my suggestion of
merging the requests; in any case, the disk hardware should be able to handle
N such requests without a seek, so it is a reasonable optimization.  It will
still be necessary to have an absolute limit on requests from each queue or
you'll run into the behaviour of early SCSI disks with tagged queueing: the
requests that *would* force a seek will never be processed at all... :-)

Thor