Date: Tue, 28 Dec 1999 02:31:51 -0500 (EST) From: Bosko Milekic <bmilekic@dsuper.net> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Kip Macy <kip@lyris.com>, "Mr. K." <bsd@inbox.org>, stable@FreeBSD.ORG Subject: Re: panic Message-ID: <Pine.OSF.4.05.9912280219270.32041-100000@oracle.dsuper.net> In-Reply-To: <199912280630.WAA01257@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 27 Dec 1999, Mike Smith wrote: !>> As far as I can tell, yes. Until default per user mbuf limitations or some !>> such thing is in place no amount of mbufs will prevent intentionally bad !>> code from downing the machine. My understanding is that this was not a !>> problem in 2.x. Already implemented in -CURRENT (the ulimit on sockbuf space, that is). Anybody want to help MFCing? !> !>It's a fundamental problem with the BSD mbuf architecture. It's not !>something that as many people were seeing with 2.2 simply because people !>weren't pushing systems as hard back then. !> !>There's a conscious tradeoff between raw performance and tuning !>requirement in the BSD mbuf allocator. You can't add more buffering once !>the system has started, so you need to tune at kernel build or load time. !>The upside from this is that certain critical network buffer operations !>are extremely efficient. !> !>Work is underway (and in fact mostly complete) to reduce the fataility of !>mbuf starvation to the system, but the fact remains that correct tuning !>of the BSD kernel is and always has been critical to performance and !>robustness. "Work" has been implemented in -CURRENT, actually. In fact, "more work" is being done on filtering out bad guys (before somebody decides to MFC, that is). The problem here is not that directly related to an mbuf starvation, or so it seems. Then again, one of the [easy] ways of checking if it is would be to of course verify complaints in /var/log/messages. In any case, -CURRENT should no longer panic on a lack of mbufs, well, at least not in the mbuf code. However, problems may remain here and there mainly for one reason: mbuf allocations not being checked for failure and resulting in either a NULL mbuf pointer, or an explicit panic from the code using the allocation routines. The solution would be to handle the shortage in other parts of the code differently. If whoever posted the original message could of course provide more detailed information regarding the crash, so that one can actually know for a fact what and where the problem is, we wouldn't be stuck here guessing. Bosko. ...... . . . . . . . . . . . . . Bosko Milekic -- bmilekic@dsuper.net . . . . . . . . . . . ...... . . WWW: http://pages.infinit.net/bmilekic/ . ................................................ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.4.05.9912280219270.32041-100000>