Hi!

On Sat, 30 Oct 2004, Chuck Silvers wrote:

[about the way vm.{anon,exec,file}{min,max} percentages are calculated]

> right, that's why I wrote it the way I did.  I agree that it's a little
> unintuitive, but the other way seems less useful.

I have to take back my earlier statement that "the current min,max limits
are quite difficult to use". They would be really useful, if one would
know what they should be. :) The main problem for me is that they don't
add up the way one would expect. Assume the following:

	- keep vm.{anon,exec,file}{min,max} as is
	- add vm.wiredmax (to control the maximum which I think is 33% now)
	- add vm.bufcache to the mix (to cover UBC+kernel)
	- make the above to add maybe 95..99% of RAM, or so
	  (at least in documentation, don't know about forcing them, etc)

Now, suddenly the same anon/exec/file limits start to make sense.
You know that you've set wiredmax to, say, 10%, and kernel/UBC takes
whatever you've told it to use, through vm.bufcache, maybe. Each limit
tells you where the memory is going, the numbers start adding up.
You know you can't push some limits too far, because kernel/wired needs
to have some, etc. You know that since you set vm.anonmin to 35%
it will actually be used as you expect it to be. No surprises, no
"rounding errors" due to hidden "costs".

That's a fantasy, since I don't know if it is feasible. But it would
make the current memory usage more explicit, more controlled,
and it would not require any changes to the anon/exec/file logic,
which otherwise makes a lot of sense. vm.wiredmax might be trivial
to add, and vm.bufcache is already there, but I have no idea if
it could be used the way I suggested. Wired usage is the biggest variable,
anyway (being anything from ~0 to the 33% max).

> the currently knobs to adjust the balance are just what I came up with,

Out of curiosity, where do the following come from (if known):

	- 2:1 active:inactive ratio
	- freetarg = 4/3 * freemin
	- page daemon freeing until free > 4*freetarg
	- wiredmax = 1/3 * physmem

> failing that, improving the documentation would also be good.
> the current documentation is really just the few lines in sysctl(3)
> about the various tunables.  if we're going to stick with the current
> knobs for a while yet, then we should probably have some examples somewhere
> of what settings can be used to achieve various goals.

As I mentioned earlier, I've already started to write a web page about
my findings so far. Since that has reached at least some minimal
level of usefulness, and since I've received quite a lot of useful
information here, here is what I have so far:

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

I know, it is far from being as coherent, consistent, complete or
compact as one would like it to be, but it is a start. All comments
are welcome and will probably affect the final result (although probably
not in a timely manner).

> also, try these settings to keep your squid in memory:
>
> vm.anonmin=93
> vm.anonmax=100
> vm.execmin=1
> vm.execmax=1
> vm.filemin=1
> vm.filemax=1

I had already gotten pretty close: 65/90, 2/4, 0/1. I guess I can be
even more aggressive with anonmin. :)


Artsi
-- 
#######======------  http://www.selonen.org/arto/  --------========########
Everstinkuja 5 B 35                               Don't mind doing it.
FIN-02600 Espoo        arto@selonen.org         Don't mind not doing it.
Finland              tel +358 50 560 4826     Don't know anything about it.