Date: Fri, 31 Dec 1999 23:53:05 -0500 (EST) From: Charles Youse <cyouse@paradox.nexuslabs.com> To: Warner Losh <imp@village.org> Cc: Mike Smith <msmith@FreeBSD.ORG>, Mikhail Teterin <mi@kot.ne.mediaone.net>, stable@FreeBSD.ORG Subject: Re: Panic: Out of mbuf clusters Message-ID: <Pine.BSF.4.20.9912312338490.79579-100000@paradox.nexuslabs.com> In-Reply-To: <199912312314.QAA18578@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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). 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 On Fri, 31 Dec 1999, Warner Losh wrote: > In message <Pine.BSF.4.20.9912312302340.79474-100000@paradox.nexuslabs.com> Charles Youse writes: > : Why aren't they dynamically allocated using the kernel memory management > : routines? > > Because it is hard to malloc in an interrupt context. It is expensive > to do this and on older hardware it was felt that it would be better > to have a large enough pool and not have to worry about the hair that > doing things dynamically would require. > > Warner > 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.BSF.4.20.9912312338490.79579-100000>