From owner-freebsd-hackers Thu Feb 22 05:00:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA15651 for hackers-outgoing; Thu, 22 Feb 1996 05:00:10 -0800 (PST) Received: from sun4nl.NL.net (sun4nl.NL.net [193.78.240.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA15645 for ; Thu, 22 Feb 1996 05:00:07 -0800 (PST) Received: from spase by sun4nl.NL.net via EUnet id AA19001 (5.65b/CWI-3.3); Thu, 22 Feb 1996 14:00:05 +0100 Received: (from root@localhost) by mercurius.spase.nl (8.6.11/8.6.11) id NAA11151 for hackers@freebsd.org; Thu, 22 Feb 1996 13:46:25 +0100 Date: Thu, 22 Feb 1996 13:46:25 +0100 From: root Message-Id: <199602221246.NAA11151@mercurius.spase.nl> To: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >From freefall.freebsd.org!owner-freebsd-hackers Wed Feb 21 10:31:09 1996 remote from sun4nl Received: from ra.dkuug.dk by sun4nl.NL.net with SMTP id AA26452 (5.65b/CWI-3.3); Wed, 21 Feb 1996 10:31:09 +0100 Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [192.216.222.4]) by ra.dkuug.dk (8.6.12/8.6.12) with ESMTP id JAA05079; Wed, 21 Feb 1996 09:57:36 +0100 Received: from localhost (daemon@localhost) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA10770 Tue, 20 Feb 1996 22:28:51 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA10754 for hackers-outgoing; Tue, 20 Feb 1996 22:28:47 -0800 (PST) Received: from baygull.rtd.com (baygull.rtd.com [198.102.68.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA10749 for ; Tue, 20 Feb 1996 22:28:44 -0800 (PST) Received: (from news@localhost) by baygull.rtd.com (8.6.9/8.6.9.1) id XAA15394; Tue, 20 Feb 1996 23:28:31 -0700 To: hackers@freebsd.org Path: freefall.freebsd.org!owner-freebsd-hackers From: nao@sbl.cl.nec.co.jp (Naoki Hamada) Newsgroups: rtd.freebsd.hackers Subject: Re: mbuf enhancement patch Date: Wed, 21 Feb 1996 09:58:33 +0900 Lines: 21 Message-Id: <199602210058.JAA17442@sirius.sbl.cl.nec.co.jp> Nntp-Posting-Host: seagull.rtd.com Sender: owner-hackers@freebsd.org Precedence: bulk > 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