From owner-freebsd-current  Tue Dec  9 21:54:30 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA18615
          for current-outgoing; Tue, 9 Dec 1997 21:54:30 -0800 (PST)
          (envelope-from owner-freebsd-current)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA18600
          for <current@freebsd.org>; Tue, 9 Dec 1997 21:54:20 -0800 (PST)
          (envelope-from bde@zeta.org.au)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id QAA08722; Wed, 10 Dec 1997 16:45:06 +1100
Date: Wed, 10 Dec 1997 16:45:06 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199712100545.QAA08722@godzilla.zeta.org.au>
To: gemohler@tgn2.tgn.net, phk@critter.freebsd.dk
Subject: Re: Namei cache?
Cc: current@freebsd.org
Sender: owner-freebsd-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>>> In current there is little you can do.
>>> 
>>> You can try to increase:
>>> 
>>> 	kern.maxvnodes
>>> 	debug.wantfreevnodes
>>
>>I see what these values currently are, but what are my boundaries and 
>>rules I have to follow in changing them..IE: stay in 4096 
>>incrememnts..dont go above 99999...etc.
>
>You'll run out of memory if you set them too high...
>
>Add 10% or so at a a time, let it run for a day before you judge
>the result...

In current there is little you can do.

Setting kern.maxvnodes has no effect unless debug.wantvnodes is set to 0.
Setting debug.wantvnodes to 0 just gives kern.maxvnodes the old function
of debug.wantvnodes.  Setting debug.wantvnodes has very little effect.
It just controls how fast the system ramps up to peak vnode allocation.
This is bogus of course.  The man page is more bogus/incomplete.

Bruce