From owner-freebsd-isp  Tue Sep 24 09:32:13 1996
Return-Path: owner-isp
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id JAA16875
          for isp-outgoing; Tue, 24 Sep 1996 09:32:13 -0700 (PDT)
Received: from saguaro.flyingfox.com (saguaro.flyingfox.com [204.188.109.253])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA16819
          for <freebsd-isp@freebsd.org>; Tue, 24 Sep 1996 09:32:05 -0700 (PDT)
Received: (from jas@localhost) by saguaro.flyingfox.com (8.6.12/8.6.10) id JAA13814; Tue, 24 Sep 1996 09:30:24 -0700
Date: Tue, 24 Sep 1996 09:30:24 -0700
From: Jim Shankland <jas@flyingfox.COM>
Message-Id: <199609241630.JAA13814@saguaro.flyingfox.com>
To: dg@root.com, jas@flyingfox.COM
Subject: Re: mb_map full
Cc: freebsd-isp@freebsd.org, robseco@wizard.teksupport.net.au
Sender: owner-isp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

David Greenman writes:

> 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:
[ ... ]

Thanks for the information.  But does making the kmem_map larger,
as you described, eliminate the panic, or just make it less
likely?  In other words, is the kmem_map now sized so that it
can never possibly fill up?  mbufs, for example (not clusters),
still come out of the kmem_map, and I don't know of any a priori
upper bound on the number of mbufs that can be consumed.  It
still seems that an unluckily timed call to malloc (resulting in a
call to kmem_malloc) with WAITOK can trigger a panic.

I will happily stand corrected if any of this is not right.

Jim Shankland
Flying Fox Computer Systems, Inc.