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