Date: Fri, 10 May 1996 10:40:48 +1000 From: Bruce Evans <bde@zeta.org.au> To: brian@mediacity.com, davidg@Root.COM Cc: current@FreeBSD.org, et-users@netrail.net, freebsd-isp@FreeBSD.org, msmith@atrad.adelaide.edu.au, randy@zyzzyva.com, stable@FreeBSD.org Subject: Re: Continued MBUF problem with ET V.35 card Message-ID: <199605100040.KAA18101@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> 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. Except in -current a couple of days ago. It no longer uses malloc() or allocation-type tracking except for one stray allocation for `mclrefcnt' in machdep.c. machdep.c also refers to to the wrong entry point for the no-wait case (kmem_alloc instead of kmem_malloc). A comment in vm_kern.c bogusly says that "only malloc() uses this routine". It is used by the mbuf allocation routines too. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605100040.KAA18101>