[I am not on tech-kern, to which this was Cc:'d, and the relevance is to
netbsd-users, so please ensure that netbsd-users remains in the recipients.]

So it seems that the sluggishness-during-I/O issue has come up
again-again-again-again-again-again.  I feel like it's a recording on
endless loop now.

I see this all the time, and my afflicted machine runs none of X, large
apps, or system builds.  Yet, for me, /usr/games/mille will stop dead in its
tracks when pkgsrc is updated.  Huh!?  After finally understanding the VM
tuning parameters and doing some minor adjusting today, I don't see the
problem at all anymore after many cycles of testing.

I believe this should be demonstrative of the fact that NetBSD's default
tuning parameters are *NOT* a good compromise starting point for NetBSD
users in general, and should be reevaluated.

Here's the current min/max defaults (as of 2.1, but I don't think these
have changed since):

vm.anonmax=80
vm.anonmin=10
vm.execmax=30
vm.execmin=5
vm.filemax=50
vm.filemin=10

So let's take a typical setup:  256MB (which is actually *high* for some
architectures or single board machines!).  These values equate to:

anonmax = 205.8 MiB
anonmin =  25.6 MiB
execmax =  76.8 MiB
execmin =  12.8 MiB
filemax = 128.0 MiB
filemin =  25.6 MiB

Now what's the problem here?  From just glancing at the list above, execmin
is obviously way too low.  Even a source tree build will typically have well
over 16 MiB of repetitively active text pages, yet 95% of the system can be
yanked from underneath text pages for file buffers and in-memory anon pages.

Take this to a 32 MiB box, which is typical for a single board machine.

anonmax = 25.6 MiB
anonmin =  3.2 MiB
execmax =  9.6 MiB
execmin =  1.6 MiB
filemax = 16.0 MiB
filemin =  3.2 MiB

Will someone please tell me what kind of box will need 1.6 MiB or less of
persistent text pages when fully running, if the box is doing anything in
userspace applications?  Something is really wrong here with the defaults.

I would suggest a compromise of something along the lines of:

vm.anonmax=70 # default = 80
vm.anonmin=10 # default
vm.execmax=40 # default = 30
vm.execmin=20 # default = 5
vm.filemax=40 # default = 50
vm.filemin=10 # default

Of all these, however, vm.execmin is the most critical (hence the subject
line).  The default should be nowhere below 20, and currently it's only one
fourth of that.  Forget the low memory boxes for a moment -- we're
sacrificing systems with typically modest memory just to make heavily
decked-out systems run a couple percent faster.  No wonder NetBSD is
publicly perceived as having serious VM paging problems.

If a system has many GiB of memory, it should be up to the admin to lower
the execmin in order to gain yet more fs or anon page cache.  It should
*not* be up to the users of systems with modest memory to raise them.

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>