On Mon, Sep 02, 2002 at 01:32:35PM -0400, Thor Lancelot Simon wrote:
> 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.

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.

> 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.

Will think about it...
My first idea was: A process usually blocks until a read is satisfied while
it could continue to run after a delayed write.

> 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

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)