In message <9510231605.AA01853@bach>  "Gordon W. Ross" wrote:
> > From: Jason Thorpe <thorpej@nas.nasa.gov>
> > Date: Sat, 21 Oct 1995 17:08:08 -0700
> 
> > > panic: kmem_malloc: mb_map too small
> 
> > This can happen if your system is dealing with alot of network traffic.  
> 
> > As computer networks get larger, and applications grow increasingly 
> > network-oriented, I would tend to favor the default NMBCLUSTERS being 
> > raised from 256/512 to 1024/2048 (without/with GATEWAY).  Just like we 
> > recently raised CHILD_MAX frm 40 to 80, the lower value just doesn't seem 
> > to make sense for modern systems anymore...
> > 
> > Comments?
> 
> We can make the problem less likely to occur by increasing NMBCLUSTERS.
> However, I think a better solution would be to make the network code
> drop packets when it can not allocate more mbufs (not panic).
> 
> Perhaps this would require a priority scheme for mbuf allocations,
> so you can drop the right ones (usually just Ethernet input).

Regardless where you start dropping packets it`s a risk. If you
drop incoming packets you may just drop the packet that releases a big
bunch of your allocated memory. (with windowsize scaling this can be 
megabytes).  Worst case you deadlock here.
Implenting the drain stuff for protocols (to drop non vital data) or keep 
buffers around for emergncys so that the upperlevel protocls can read
at least the protocol information (eg. acks) would be the perfect solution.

I admit dropping packts is better than panicing,  but it`s also only a
workaroud and not the solution (and yes the deadlock sceanrio is unlikely
to happen on normal machines, server system should be configured for worth
case situations).

Stefan

> 
> Gordon Ross

--
Stefan Grefen                          Convex Computer GmbH, Frankfurt, Germany
grefen@convex.com		       Phone: +49-69-665270
fortune: "You can't make a program without broken egos."