Date: Fri, 30 Nov 2001 17:48:16 -0800 From: Luigi Rizzo <rizzo@aciri.org> To: Leo Bicknell <bicknell@ufp.org> Cc: Mike Silbersack <silby@silby.com>, Alfred Perlstein <bright@mu.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: TCP Performance Graphs Message-ID: <20011130174816.H33041@iguana.aciri.org> In-Reply-To: <20011130203905.A2944@ussenterprise.ufp.org> References: <20011130171418.B96592@ussenterprise.ufp.org> <Pine.BSF.4.30.0111301717290.10049-100000@niwun.pair.com> <20011130173033.G33041@iguana.aciri.org> <20011130203905.A2944@ussenterprise.ufp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 30, 2001 at 08:39:05PM -0500, Leo Bicknell wrote: > On Fri, Nov 30, 2001 at 05:30:33PM -0800, Luigi Rizzo wrote: > > I just committed to current (and soon to stable) some code to log > > _failures_ in mbuf allocations, but that is only meant as an aid > > to remove worse code in the drivers. > > Note that if we implement a 'fair share' buffering scheme we would > never get a failure, which would be a good thing. Unfortuantely > fair share is relatively complicated. i don't get this. There is no relation among the max number of mbufs and their potential consumers, such as network interfaces, sockets, dummynet pipes, and others. And so it is unavoidable that even giving 1 mbuf each, you'll eventually fail an allocation. > > (Plus, just setting a threshold is not good, you also want > > some histeresys, because you can easily conceive a system that > > runs at XX % mbuf occupation, whatever XX you pick.) > With fair share or some other type of setup I would agree. Given > our current 'things fail badly if you run out' I think a warning I should have said "any XX != 100". But note that what you say about bad failures is not really true. Many pieces of the kernel now are pretty robust in the face of failures -- certainly dummynet pipes, and the "sis" and "dc" drivers are, or i could not have tested the "run out of mbuf" message code which i just committed. I just think that the latter should not became a further source of trouble by filling up /var/log. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011130174816.H33041>