Date: Mon, 23 Sep 1996 20:25:38 -0700 From: David Greenman <dg@root.com> To: Jim Shankland <jas@flyingfox.COM> Cc: freebsd-isp@freebsd.org, robseco@wizard.teksupport.net.au Subject: Re: mb_map full Message-ID: <199609240325.UAA03226@root.com> In-Reply-To: Your message of "Mon, 23 Sep 1996 08:52:19 PDT." <199609231552.IAA12960@saguaro.flyingfox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609240325.UAA03226>