Date: Thu, 09 May 1996 09:33:11 -0700 From: David Greenman <davidg@Root.COM> To: Randy Terbush <randy@zyzzyva.com> Cc: brian@mediacity.com, msmith@atrad.adelaide.edu.au (Michael Smith), et-users@netrail.net, freebsd-isp@freebsd.org, stable@freebsd.org, current@freebsd.org Subject: Re: Continued MBUF problem with ET V.35 card Message-ID: <199605091633.JAA02520@Root.COM> In-Reply-To: Your message of "Thu, 09 May 1996 11:05:00 CDT." <199605091605.LAA24496@sierra.zyzzyva.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >> Hit Dennis on the head and get him to admit that it's his drivers 8) >> > >> >Some months ago, I worked with Dennis to track down the mbuf leak >> >problem. The leak was in FreeBSD code, not his driver. >> >> Yes, and for the record this was caused by a small change to the MGET/MFREE >> macros. We used to have a private pool of mbufs to optimize performance, but >> this was found to conflict with the allocation-type tracking in malloc() and >> lead to system instabilities. By reverting the macros back to their originals, >> the code in Dennis's driver that allocated and freed mbufs was still sticking >> them in this private pool - one the rest of the system didn't know about, and >> thus the "leak". >> There have been no changes to the mbuf allocation code since then. >> >> -DG > >Could someone help me with version numbers in these changes? > >I'm finding that the problem exists in 2.1.0 and -stable. >What version was changed? >What version was reverted? >In which branch is this fixed? > >This discussion is very helpful. Please expand. The above is not applicable to FreeBSD 2.1. The problem that Dennis encountered was in FreeBSD 2.0, and it wasn't really a problem with FreeBSD. The solution was for Dennis to recompile his driver. No source changes were needed. ...but to answer your question directly: (/sys/sys/mbuf.h) ---------------------------- revision 1.8 date: 1994/11/04 00:28:38; author: davidg; state: Exp; lines: +4 -32 Backed out mbuf performance improvement. mbufs are allocated with various different types, and with the 'local cache', what is freed isn't necessarily what was originally malloced. This screws malloc's statistics and type allocation limits, resulting eventually in a deadlock when one of the limits is bogusly reached. Recent performance tests on a Pentium machine indicate no improvement with this optimization anyway (this is something to be looked at further). ---------------------------- -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605091633.JAA02520>