Date: Sat, 13 Apr 1996 20:58:35 -0700 From: David Greenman <davidg@Root.COM> To: Brian Tao <taob@io.org> Cc: FREEBSD-HACKERS-L <freebsd-hackers@freebsd.org> Subject: Re: pmap_zero_page and kmem_malloc panics Message-ID: <199604140358.UAA02986@Root.COM> In-Reply-To: Your message of "Sat, 13 Apr 1996 21:07:34 EDT." <Pine.NEB.3.92.960413203938.27644F-100000@zap.io.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> For some reason, our Web/FTP server has been crashing/hanging a >lot lately. I was able to take down the reason for two recent ones: > >panic: kmem_malloc: kmem_map too small >panic: pmap_zero_page: CMAP busy > > The mysterious process deadlock hang also hit a couple of times >(can switch virtual consoles, can ping, but nothing else), with no >helpful errors logged. > > I'm going to upgrade to the latest snapshot too see if this >problem goes away. The kernel has maxusers=128, SysV IPC options >turned on, NMBCLUSTERS=8192, OPEN_MAX=1024, CHILD_MAX=512 and >MAXMEM=131072. It isn't running out of mbufs (although it did hit >7202 out of 8192 once) and I doubt it is getting anywhere close to >hitting swap. 'top' usually shows about 50MB free when there isn't a >mirror process running. Hi, Brian. The problem here appears to be that your machine is running out of kernel VM for its malloc area. There was a bug in 2.1R and previous releases that caused the space for the malloc VM to be incorrectly sized. The bug was fixed in these commits to kern_malloc.c and related files: ---------------------------- 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. ---------------------------- I strongly encourage you to upgrade the affected machines to -stable. -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?199604140358.UAA02986>