Date: Fri, 31 Dec 1999 16:44:41 -0800 (PST) From: Alfred Perlstein <bright@wintelcom.net> To: Charles Youse <cyouse@paradox.nexuslabs.com> Cc: Warner Losh <imp@village.org>, 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.21.9912311639140.227-100000@fw.wintelcom.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. > > 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? One of the problems with all such schemes is that you then have a chance to wire down all the kernel memory with network buffers, It's a bit bogus, but at the same time better to impose a limit that specifically tells you what's hogging what and why. Also, mbufs are allocated from a special pool where a fixed size allows certain 'tricks' to work that the network stack depends on. Although new ideas are welcome it's really better for you to research the current system before giving suggestions that are unfortunatly not feasable. Grab a copy of 'design and implementation' and trod through the sources, people have and will improve the system, but it takes more research. -Alfred > > 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 > -Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bright@wintelcom.net] 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.21.9912311639140.227-100000>