Re: 5.2-RELEASE crash

From: Scott Long <scottl_at_freebsd.org>
Date: Sat, 31 Jan 2004 09:37:42 -0700
Andre Guibert de Bruet wrote:
> On Fri, 30 Jan 2004, Magnus Dahlstedt wrote:
> 
> 
>>panic: kmem_malloc(16384): kmem_map too small: 275243008 total allocated
>>cpuid = 1;
>>Debugger("panic")
>>Stopped at      Debugger+0x4f:  xchgl   %ebx,in_Debugger.0
>>db> trace
>>Debugger(c06c2ccd,1,c06d5a05,e40a6a74,100) at Debugger+0x4f
>>panic(c06d5a05,4000,1067e000,e40a6aa0,c0518254) at panic+0x14a
>>kmem_malloc(c10310a0,4000,402,e40a6aec,c064c19e) at kmem_malloc+0x101
> 
> -- 8< -- snip -- 8< --
> 
>>real memory  = 2146942976 (2047 MB)
>>avail memory = 2080309248 (1983 MB)
> 
> 
> You are using a large amount of RAM and using the default kmem_map sizing
> options. What you want to do to fix this is manually increase the
> KVA_PAGES tunable to something like 640 (By putting "options
> KVA_PAGES=640" in your kernel config file).
> 
> You will also want to grow your kmem_map by changing the following:
> options         VM_KMEM_SIZE_MAX=(512*1048576)
> options         VM_KMEM_SIZE_SCALE=2
> 
> On a busy system with 3.5GB, I found that using 768MB for VM_KMEM_SIZE_MAX
> helps it run flawlessly. These values are not set in stone, and should
> only be used as a guide. In other words, do your own testing! :-)
> 

Also, the scaling of kern.maxvnodes doesn't work very well.  On a large
memory system, it will typically set this to 200,000-300,000.  If you
don't need this many, then it is easier to just crank it down to a more
reasonable level than fiddle with the KMEM parameters.

Scott
Received on Sat Jan 31 2004 - 07:39:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:41 UTC