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

next in thread | raw e-mail | index | archive | help
>From owner-freebsd-hackers  Wed Feb 21 09:42:02 1996 remote from spase
Received: from sun4nl.UUCP (uucp@localhost) by mercurius.spase.nl (8.6.11/8.6.11) with UUCP id JAA23074 for spase.nl!dutchman; Wed, 21 Feb 1996 09:29:24 +0100
Received: from spase by sun4nl.NL.net via EUnet
	id AA16553 (5.65b/CWI-3.3); Wed, 21 Feb 1996 09:17:25 +0100
Received: from sun4nl.UUCP (uucp@localhost) by mercurius.spase.nl (8.6.11/8.6.11) with UUCP id JAA22209 for spase.nl!dutchman; Wed, 21 Feb 1996 09:00:21 +0100
Received: from spase by sun4nl.NL.net via EUnet
	id AA13317 (5.65b/CWI-3.3); Wed, 21 Feb 1996 08:47:52 +0100
Received: from sun4nl.UUCP (uucp@localhost) by mercurius.spase.nl (8.6.11/8.6.11) with UUCP id IAA21199 for spase.nl!dutchman; Wed, 21 Feb 1996 08:29:55 +0100
Received: from spase by sun4nl.NL.net via EUnet
	id AA10181 (5.65b/CWI-3.3); Wed, 21 Feb 1996 08:19:04 +0100
Received: from sun4nl.UUCP (uucp@localhost) by mercurius.spase.nl (8.6.11/8.6.11) with UUCP id HAA20261 for spase.nl!dutchman; Wed, 21 Feb 1996 07:59:51 +0100
Received: from spase by sun4nl.NL.net via EUnet
	id AA07267 (5.65b/CWI-3.3); Wed, 21 Feb 1996 07:46:58 +0100
Received: from sun4nl.UUCP (uucp@localhost) by mercurius.spase.nl (8.6.11/8.6.11) with UUCP id HAA19565 for spase.nl!dutchman; Wed, 21 Feb 1996 07:37:57 +0100
Received: from freefall.freebsd.org by sun4nl.NL.net via EUnet
	id AA06027 (5.65b/CWI-3.3); Wed, 21 Feb 1996 07:26:57 +0100
Received: from sun4nl.UUCP (uucp@localhost) by mercurius.spase.nl (8.6.11/8.6.11) with UUCP id HAA18903 for spase.nl!dutchman; Wed, 21 Feb 1996 07:19:31 +0100
Received: from ra.dkuug.dk by sun4nl.NL.net with SMTP
	id AA04926 (5.65b/CWI-3.3); Wed, 21 Feb 1996 07:13:22 +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 GAA03152; Wed, 21 Feb 1996 06:42:58 +0100
Received: from localhost (daemon@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA25735
          Tue, 20 Feb 1996 18:24:11 -0800 (PST)
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id SAA25720
          for hackers-outgoing; Tue, 20 Feb 1996 18:24:07 -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 SAA25675
          for <hackers@freebsd.org>; Tue, 20 Feb 1996 18:24:00 -0800 (PST)
Received: (from news@localhost) by baygull.rtd.com (8.6.9/8.6.9.1) id TAA12510; Tue, 20 Feb 1996 19:23:47 -0700
To: mercurius!freebsd.org!hackers
Path: freefall.freebsd.org!owner-freebsd-hackers
From: mercurius!Root.COM!davidg (David Greenman)
Newsgroups: rtd.freebsd.hackers
Subject: Re: mbuf enhancement patch
Date: Tue, 20 Feb 1996 15:31:50 -0800
Lines: 23
Message-Id: <199602202331.PAA04282@Root.COM>
Nntp-Posting-Host: seagull.rtd.com
Sender: mercurius!freebsd.org!owner-hackers
Precedence: bulk

>> I found mbuf's are not buffered though mclusters are. So here is my
>> patch for /sys/sys/mbuf.h. This seems to provide me slightly good
>> network performance.
>
>Did one of the core team members accept these patches
>officially ?! Will they go into -current ?

   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.
   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).

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project



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