On Fri, 28 Oct 2005, James Chacon wrote:

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

However, 256M is still pretty large, as I mentioned.  On a smaller memory
machine (such as embedded, 16-32M max), you wouldn't necessarily want
filemax that low. as you could starve for file read buffers.  I also see
possible problems with doing, e.g., source tree builds on a 256M machine
with execmin remaining so low.

I'm trying to come up with a "reasonable compromise" set of defaults that
has at least some memory reserved for different types, so that none of them
will starve in the normal case.

On Sat, 29 Oct 2005, SODA Noriyuki wrote:

> > 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
>
> Leaving vm.filemax that large isn't a good thing.

My local setting is filemax=25, filemin=5; but I wanted to be more
conservative on my default adjustment suggestions.

> Also, increasing vm.exec{min,max} often causes bad effect on
> machines which are really tight about free memory (because
> it may make anonymous pages paged out).

It doesn't matter if anon pages are all over the place if the code is not
there to use them.  Unlike code which is fixed in place in virtual space and
often jumps all over memory due to sparse linking, allocated anon memory is
somewhat packed such that the most recently used pages tend to cluster
together (unless I've misunderstood what our malloc(3) does).

I may see what you mean, though.  Even in that case, execmin=5 is still far
too low for a default based on how much physical memory 5% represents on
machines with modest memory totals.  Perhaps 12?  15?

> http://mail-index.netbsd.org/tech-kern/2005/03/06/0004.html
> http://mail-index.netbsd.org/tech-kern/2005/03/10/0000.html

I'll try out these params later today.

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