>> Thor, I find -current to be almost unusable for interactive work when
>> there's something I/O-intensive running at the same time.  I have
>> NEW_BUFQ_STRATEGY enabled, as best I can tell.  Here are my vm. sysctl
>> values, on a 256M machine:
> 
> I can confirm this.  I'm using i386 1.6ZH with NEW_BUFQ_STRATEGY and
> soft updates on IDE disks.  My vm sysctl values are the same as below.
> Yesterday, I upgraded Mozilla and MozillaFirebird on the machine.
> While the source files of those packages was un-tarring, the system
> was dead in the water, and not only for interactive use.  That machine
> also servers NFS from some other disks, and access to those from
> network clients also halted during all of the heavy I/O activity.

I have several -current machines with softdeps. Two, an NFS server
and client - when I do a 'nice +20 cvs up' in pkgsrc on the client,
both machines essentially grind to a halt, with tiny spurts of
other activity, until the cvs up is completed. Several times lately,
a cdrecord session has failed, indicating a buffer underrun yet
there was no evidence of a 'buffer underrun'. It appears the FS
just quit supplying data to the cdrecorder long enough to trash
the write.  The KDE login sequence which used to take about 20
seconds on several XP2000-2200s now take a minute to a minute and
a half.  Konqueror startups take about 20 seconds on these same
machines when they used to take about two. Note that these access
likely many small config files. xterms, etc. start up immediately,
as usual.

vm.loadavg: 0.82 0.75 0.78
vm.nkmempages = 32743
vm.anonmin = 10
vm.execmin = 5
vm.filemin = 10
vm.maxslp = 20
vm.uspace = 16384
vm.anonmax = 80
vm.execmax = 30
vm.filemax = 50
vm.bufcache = 30
vm.bufmem_lowater = 10053120
vm.bufmem_hiwater = 160849920

On a machine that isn't really very busy right now.