On 22 Mar 1999 12:38:31 -0800 
 Michael Graff <explorer@flame.org> wrote:

 > >  > > (1)  What controls how much memory the pool system can use?
 > >  > > 
 > >  > 	It looks like its still dependent on NMBCLUSTERS
 > >  > 	arch/XXX/XXX/machdep.c defined the mb_map size in terms of
 > >  > 	VM_MBUF_SIZE, which is defined as a multiple of NMBCLUSTERS.
 > > 
 > > Correct.
 > 
 > So, if I want to increase this limit to, say, 64M of kernel memory, I
 > can do this with
 > 	NMBCLUSTERS=?
 > 
 > That is, what units is this in?  I'm guessing 2048 (cluster size)
 > bytes.

No, "clusters" in this sense is the historic "page cluster", i.e.
VM page size (as opposed to hardware page size :-)  In the NetBSD
kernel, CLBYTES == PAGE_SIZE :-)

Confusing enough yet? :-)

So, on i386, 4k.  On Alpha, 8k.  On SPARC, 8k.  Etc.

 > also, how does that interact with NKMEMCLUSTERS=?

It's completely independent.  Except that mbufs are mapped via kmem_map,
and are thus dependent on NKMEMCLUSTERS.  Only mbuf clusters are mapped
via mb_map.

 > This is the number I have now, and it runs out of memory pretty fast.
 > 
 > When looking at the memory stats, the "Memory statistics by type" has
 > a limit of 19661K.  Does this mean the pool system gets up to that
 > much space?  I don't mind giving the kernel 1/4th of my ram if it
 > makes it able to handle a few thousand connections, but I'd rather not
 > throw 64M at it then find out it won't help.

KMBCLUSTERS is the amount of kernel VA space you're throwing at it.

The pool allocator does NOT fall under the malloc limits that are imposed
if KMEMSTATS is enabled.

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>