Date: Sat, 1 Jan 2000 05:08:27 -0500 (EST) From: Bosko Milekic <bmilekic@dsuper.net> To: Charles Youse <cyouse@paradox.nexuslabs.com> Cc: stable@FreeBSD.ORG Subject: Re: Panic: Out of mbuf clusters Message-ID: <Pine.OSF.4.05.10001010446001.31871-100000@oracle.dsuper.net> In-Reply-To: <Pine.BSF.4.20.9912312338490.79579-100000@paradox.nexuslabs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 31 Dec 1999, Charles Youse wrote: !> !>Perhaps, then, it would be best to monitor the number of free clusters !>and when it hits a low watermark, to allocate more - perhaps by flagging !>an AST to obviate allocating clusters from within an interrupt context. It's difficult to understand what you mean here. Revise the present implementation with much more detail to notice the pitfall. We could start explaining everything here but, believe me, it's probably way faster and more convenient for you to just read the code and sort of scribble up the ideas. ;-) !> !>Stated more specifically, the mbuf management routines, which can be !>called in an interrupt context, should be responsible for monitoring the !>levels and triggering the AST. The AST handler's job would be to stay !>ahead of the game to prevent interrupt handlers from digging the !>cluster-well dry (which would still result in a panic). Hmm, I'll add to what I mentionned above... review the implementation in -CURRENT at the moment to see exactly how it works when the panic() is not there. !> !>A certain part of my instincts tell me that this is a dirty hack, I don't !>think it's possible to devise a scheme based on this idea that could be !>proven [mathematically] not to result in a panic under certain conditions. !>On the other hand, I think if the allocator is smart enough it can !>probably cover most of the real-world cases without being a memory hog. !> !>Comments? !> !>Chuck It's somewhat difficult to figure out how to properly manage resources such as mbufs or mbuf clusters which are allocated from a fixed `zone.' The fact of the matter is, if you're willingly really pushing the system to, literally, its "limit," you'll run out and have to deal with it. Ideally, what has to be done to properly handle a situation such as this one (at least in my opinion), would be to always split the problem up in several sub-categories. This way, you'll know specifically what you're dealing with, and therefore possibly come up with a more flexible solution. In the case of mbufs, for instance, you can consider: (i) Shortage as a result of a [local] DoS. (ii) Shortage as a result of a remote DoS. (iii) Shortage as a result of much network activity (etc.) In -CURRENT, the `wait' code and all that other mumbo jumbo at the mbuf layer provides a "base" or "service" for some of the above. Now, for instance, we can look into solving (i) at a little "higher" level -- for example, in sosend() and soreceive() we can contribute to the `accounting' already in place by figuring out a way to track the variation (delta) of allocated mbufs after all mbuf clusters have been starved, and kill the offending process accordingly. Not only will this allow us to kill offending processes, but it will also help with the amount of time spent _inside the kernel_ waiting for something to be freed up. As for (ii) and in some cases even (iii), you may want to look at several things. For example, going through the nfs or netinet code to insure proper handeling (at that level) of an mbuf allocation failure would be _very_ helpful, at least for starters. Hopefully this was of some help... Bosko. -- Bosko Milekic Email: 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.10001010446001.31871-100000>