Subject: Re: New device buffer queue strategy
To: Manuel Bouyer <email@example.com>
From: Thor Lancelot Simon <firstname.lastname@example.org>
Date: 09/02/2002 15:27:23
On Mon, Sep 02, 2002 at 09:15:13PM +0200, Manuel Bouyer wrote:
> On Mon, Sep 02, 2002 at 02:55:07PM -0400, Thor Lancelot Simon wrote:
> > 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
> When you say "run time", do you mean that the admin can change it,
> or that the system will change it dynamically based on some parameter ?
I believe it changes dynamically, and I *think* the parameter in control is
observed latency for each queue -- maximum and average.
You have to be careful tuning for minimum latency; you can just plain wreck