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 - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)