Subject: Re: NEW_BUFQ_STRATEGY
To: None <firstname.lastname@example.org>
From: Juergen Hannken-Illjes <email@example.com>
Date: 12/01/2003 19:11:59
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:
> > On Sun, Nov 30, 2003 at 10:33:47AM -0800, Jason Thorpe wrote:
> > >
> > > On Nov 28, 2003, at 2:10 PM, Chuck Silvers wrote:
> > >
> > > >has anyone had any problems with NEW_BUFQ_STRATEGY lately?
> > > >is there consensus on whether or not this is ready to become the
> > > >default?
> > >
> > > I think the consensus is that it's stable, but I heard that it can have
> > > some pretty horrible performance effects with some file systems if
> > > they're exported by NFS.
> > As it seems to be stable the comment 'Use it with caution...' should be
> > removed from the config files.
> > 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?
While it helps in the large-write vs. small-read case as described above I
suppose it becomes slow in the large-read or many-read case because
1) the writes are stalled for a longer time
2) the reads are processed first-come first-serve
3) the seek order is broken by the reads
A web server under load would be a good test configuration.
It should have root/usr/swap/data on multiple disks.
Juergen Hannken-Illjes - firstname.lastname@example.org - TU Braunschweig (Germany)