Date: Thu, 27 Jun 1996 13:51:21 -0700 From: David Greenman <davidg@root.com> To: Joe Greco <jgreco@brasil.moneng.mei.com> Cc: hackers@freebsd.org Subject: Re: kmem_malloc: kmem_map too small Message-ID: <199606272051.NAA03920@root.com> In-Reply-To: Your message of "Thu, 27 Jun 1996 14:23:52 CDT." <199606271923.OAA10989@brasil.moneng.mei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Just a note, I saw the message from David about this.. > >> >I got a panic similar to the above every 15 minutes no a bsd 2.1R with >> >12MB ram, 486/66 and apache 1.0.3 >> > >> >Anyone know what that error means? >> >> It means that the kernel ran out of malloc space. Pretty incredible >> considering that it should have 32MB to work with. This is likely an >> indicator that you have one or more kernel config parameters set in >> the twilight zone. > >I just ran into this. The system is a 256MB P133 running INN, with a fair >amount of shared memory in use. I have traditionally tweaked maxusers to be >2 * #MB_of_RAM so it had maxusers 512 :-) (I am shooting to see this >machine hit 300-400 nnrp users, yes, I realize maxusers does not necessarily >have to directly relate to that number, but...) > >The twilight zone is all relative. :-) ---------------------------- revision 1.19 date: 1996/01/29 11:12:37; author: davidg; state: Exp; lines: +7 -3 Implement what I mentioned in rev 1.18: limit per-bucket allocations to 60% of physical memory or 60% of malloc area size, whichever is smaller. ---------------------------- revision 1.18 date: 1996/01/29 09:58:34; author: davidg; state: Exp; lines: +9 -7 Fixed two bugs in the calculation of the malloc area (kmem_map) size: 1) The calculation didn't account for NMBCLUSTERS, so if a large number of clusters was specified, it would leave little or no space for kernel malloc. 2) It was bogusly restricted to v_page_count. This doesn't take into account the sparseness of the malloc area and would have caused problems on machines with small amounts of memory. It should probably instead be changed to set the malloc limit to be constrained by the amount of memory, but I didn't do this. ---------------------------- revision 1.12.4.1 date: 1996/01/29 11:20:25; author: davidg; state: Exp; lines: +13 -7 Retrofitted changes from revs 1.18 and 1.19: fix bugs with malloc area size calculations. --- Since nmbclusters is tied to maxusers unless you override it in the config file, a setting of 512 will likely make the malloc pool (kmem_map) too small for the kernel to allocate the space it needs for other things. It appears that you haven't updated your kernel sources to -stable to get the fixes mentioned above. Note also that even with the bugfix, you're treading very close to the kernel VM limits. Going higher than this requires source code changes to move the base of the kernel VM down in memory. This has not been done in general because of BSD/OS compatibility (BSDI does some really stupid things in crt0 that force a specific user stack address...and this pretty much requires that the entire kernel VM layout to be specific, too). If we didn't care about BSD/OS compatibility, then this wouldn't be an issue. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606272051.NAA03920>