Date: Wed, 21 Feb 1996 09:58:33 +0900 From: Naoki Hamada <nao@sbl.cl.nec.co.jp> To: davidg@Root.COM Cc: andreas@knobel.gun.de, hackers@FreeBSD.org, current@FreeBSD.org Subject: Re: mbuf enhancement patch Message-ID: <199602210058.JAA17442@sirius.sbl.cl.nec.co.jp> In-Reply-To: David Greenman's message of "Tue, 20 Feb 1996 15:31:50 -0800" <199602202331.PAA04282@Root.COM> References: <199602202331.PAA04282@Root.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
> No. The performance improvemment is actually quite small and the effect of >this is that any buffers malloced up to the high water mark won't be available >to other parts of the system after they are freed. We generally try to avoid >private pools of buffers unless it's absolutely necessary - which is case for >mbuf clusters, for example, which has a mechanism for maintaining reference >counts that requires them to be allocated out of a private pool. Agreed. Sounds quite reasonable. > We once had changes similar to the ones you've provided, except we had it >so that the buffers over a certain threshold were returned back to malloc. The >problem with this was that the malloc type was lost in the process and this >messed up the malloc-type accounting (which eventually leads to malloc >failures). I found the ep driver always keeps some mbuf's in its pool. Is this because mbuf allocation is too expensive for boards which equip small receive buffer? If this is the case, some improvement (not mine :-) is desirable. -nao
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602210058.JAA17442>