From owner-freebsd-hackers Tue Feb 20 18:24:07 1996 Return-Path: owner-hackers 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 ; 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: hackers@freebsd.org Path: freefall.freebsd.org!owner-freebsd-hackers From: davidg@Root.COM (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: owner-hackers@freebsd.org 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