From owner-freebsd-isp Mon Sep 23 20:24:37 1996 Return-Path: owner-isp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA00496 for isp-outgoing; Mon, 23 Sep 1996 20:24:37 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA00476 for ; Mon, 23 Sep 1996 20:24:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id UAA03226; Mon, 23 Sep 1996 20:25:38 -0700 (PDT) Message-Id: <199609240325.UAA03226@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Jim Shankland cc: freebsd-isp@freebsd.org, robseco@wizard.teksupport.net.au Subject: Re: mb_map full In-reply-to: Your message of "Mon, 23 Sep 1996 08:52:19 PDT." <199609231552.IAA12960@saguaro.flyingfox.com> From: David Greenman Reply-To: dg@root.com Date: Mon, 23 Sep 1996 20:25:38 -0700 Sender: owner-isp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Every 'once in a blue moon' ( 3-6 months) one of our servers >> crashes with the following error: >> >> Sep 23 02:24:26 wizard kernel: mb_map full >> >> Before anyone says anything, I know I need to upgrade this >> machine to 2.1.5. However, aside from this problem it runs >> flawlessly and the upgrade is planned for next month. It is >> currently running FreeBSD 2.0-RELEASE GENERIC kernel. > >Also `panic("kmem_malloc: kmem_map too small")' caused by, e.g., >a fork() when running with high network activity (mbufs come >out of the kmem_map) and little physical memory. Granted, when >you're out of memory, you're out of memory, but returning >EAGAIN instead of panicking would seem to be more in the spirit >of graceful degradation :-). > >This was 2.1.0-RELEASE; haven't seen this yet under 2.1.5, and >haven't yet taken a close look to see if it's been fixed; but >the kmem_malloc code, at least, looks about the same as under >2.1.0. The kmem_map full panic was the result of a mis-calculation of the size of the map in 2.1R. The calculation didn't account for the mb_map being a submap of it, and thus large mb_maps would leave little space left over for the [much more important] kmem_map. This was fixed in post-2.1 with the following commit: ---------------------------- 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. (#2 fixed in rev 1.19) ---------------------------- 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. ...rev 1.12.4.1 was the version released in 2.1.5R. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project