Todd Gruhn wrote:

>I just googled the vm stuff and got a useful page:
>
>http://www.selonen.org/arto/netbsd/vm_tune.html
>
>it looks like part of the NetBSD Online Manual...
>
>Todd
>  
>
Thanks, that looks very helpfull.

The current online quide has a chapter on tuning, but it
is a very different story:

http://www.netbsd.org/guide/en/chap-tuning.html

funny to see... he was prompted to write this by a slowly
growing squid process that, as its memory allocation
approached and exceeded about 1/3rd of the total amount of
physical memory it was already starting to use swap....

This sounds only too familiar to me, though my conclusions
were entirely different. See thread started at:
http://mail-index.netbsd.org/tech-kern/2004/11/27/0004.html
(in retrospect an inappopriate list)

There is a fundamental issue in the implementation of the
realloc function which makes that a program which slowly
uses more and more memory will:
1) In total use almost three times as much memory as
the programmer thinks he/she has allocated
2) Unavoidably touch all allocated pages (realloc fn does
that), which is very bad on an OS overcommitting resources
3) Unavoidably run into swap when there should really be
no reason to do so.

Using a slightly different realloc implementation 1) can
be reduced to two times, using mmapped pages there should
be no SBRK related wastage at all.
The overcommitting of resources is an OS design choise,
and IMHO not the smartest. It alleviates the prudent use of
memory from application programmers and gives them free
reign allocating much more than they will ever use (or given
the hardware limitations be able to use). Unfortunately it
also means that ANY program, even when requesting moderate
(and reasonable) amounts of memory, may be killed at any
time. (Re)alloc doesnt get the chance to return NULL in some
cases.

At the end it all comes together....


With kind regards,

Theo.