14 messages in org.freebsd.freebsd-ispRe: Continued MBUF problem with ET V....| From | Sent On | Attachments |
|---|---|---|
| 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: | Bruce Evans (bd...@zeta.org.au) | |
| Date: | May 9, 1996 5:40:28 pm | |
| List: | org.freebsd.freebsd-isp | |
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