Subject: Re: Finally increasing vm.execmin by default
To: Todd Vierling <email@example.com>
From: James Chacon <jmc@NetBSD.org>
Date: 10/28/2005 10:46:44
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:
and ended up with this in sysctl.conf:
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.
> 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):
> 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 <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>