On Fri, Oct 28, 2005 at 11:28:55AM -0400, Todd Vierling wrote:
> [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 followed the suggestion on this page:

http://www.selonen.org/arto/netbsd/vm_tune.html

and ended up with this in sysctl.conf:

vm.anonmin=70
vm.anonmax=89
vm.execmin=4
vm.execmax=10
vm.filemin=0
vm.filemax=1

On my machines with anywhere from 256M->1G I now get completely reasonable
response rates and updating any source tree doesn't cause the machine to
stop cold. Even on the box I've been testing java on things stay reasonable.

James



> 
> 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>
> 
>