Subject: Re: New device buffer queue strategy
To: Thor Lancelot Simon <email@example.com>
From: Juergen Hannken-Illjes <firstname.lastname@example.org>
Date: 09/02/2002 19:39:56
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
> Good work, though! Thanks very much!
Juergen Hannken-Illjes - email@example.com - TU Braunschweig (Germany)