Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Feb 1996 13:46:25 +0100
From:      root <root@spase.nl>
To:        hackers@freebsd.org
Message-ID:  <199602221246.NAA11151@mercurius.spase.nl>

next in thread | raw e-mail | index | archive | help
>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 <hackers@freebsd.org>; 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602221246.NAA11151>