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

For local process it's likely that a process doing a lot of read will
have to write at some time, and that will decrease the read load.
But in a network environnement this may not be true.

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

Not all writes are async. Especially file creations in the !softdep
case, this is why splitting requests sync/async instead of read/write
may be better.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
--