Subject: Re: panic: kmem malloc: mb_map too small
To: Gordon Ross <firstname.lastname@example.org>
From: Stefan Grefen <email@example.com>
Date: 10/24/1995 04:26:12
In message <9510231605.AA01853@bach> "Gordon W. Ross" wrote:
> > From: Jason Thorpe <firstname.lastname@example.org>
> > 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
> Gordon Ross
Stefan Grefen Convex Computer GmbH, Frankfurt, Germany
email@example.com Phone: +49-69-665270
fortune: "You can't make a program without broken egos."