|Randy Terbush||May 8, 1996 3:23 pm|
|Michael Smith||May 8, 1996 6:48 pm|
|Brian Litzinger||May 9, 1996 1:28 am|
|Jordan K. Hubbard||May 9, 1996 1:51 am|
|Michael Smith||May 9, 1996 1:58 am|
|David Greenman||May 9, 1996 5:17 am|
|Randy Terbush||May 9, 1996 8:58 am|
|Randy Terbush||May 9, 1996 9:04 am|
|David Greenman||May 9, 1996 9:32 am|
|Randy Terbush||May 9, 1996 9:51 am|
|Gary Palmer||May 9, 1996 11:49 am|
|Brian Litzinger||May 9, 1996 4:48 pm|
|Bruce Evans||May 9, 1996 5:40 pm|
|Michael Dillon||May 9, 1996 9:40 pm|
|Subject:||Re: Continued MBUF problem with ET V.35 card|
|From:||David Greenman (dav...@Root.COM)|
|Date:||May 9, 1996 9:32:51 am|
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.
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:
---------------------------- 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).
David Greenman Core-team/Principal Architect, The FreeBSD Project