Subject: Re: NEW_BUFQ_STRATEGY
To: None <tech-kern@netbsd.org>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-kern
Date: 12/01/2003 13:35:23
On Mon, Dec 01, 2003 at 09:13:45AM -0800, Chuck Silvers wrote:
> On Mon, Dec 01, 2003 at 10:32:43AM +0100, Juergen Hannken-Illjes wrote:
> > 
> > This should never become the default. It works well on one-user, one-disk
> > desktop machines. The interactive processes are more responsive while
> > big files are written (taking a CD image for example).
> > 
> > I don't think it runs well on multi-user, multi-disk servers. As I don't
> > have this class of machines I cannot test it.
> 
> 
> if you haven't tested such a configuration, why do you think it doesn't
> run well?  can you give some details on what test I could run with what
> configuration to expose such problems?

I think some relevant benchmarks might be found in the original trickle-sync
paper (this policy is similar to the "read priority" they describe some
System V buffer caches implementing, with mixed results).

SGI has an interesting general-purpose policy with two queues, pulling a
configurable number of requests from each queue in turn, that is described
in the release notes for a recent version of Irix.  It appears to perform
reasonably well for both interactive and fileserver workloads and might be
a better default than either our current policy or NEW_BUFQ_STRATEGY.  I've
posted a pointer to it here before -- if anyone wants to implement this but
can't find the details I'll dig them up again.

-- 
 Thor Lancelot Simon	                                      tls@rek.tjls.com
   But as he knew no bad language, he had called him all the names of common
 objects that he could think of, and had screamed: "You lamp!  You towel!  You
 plate!" and so on.              --Sigmund Freud