From owner-freebsd-hackers  Mon May 22 22:50:28 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id WAA08439
          for hackers-outgoing; Mon, 22 May 1995 22:50:28 -0700
Received: from Root.COM (implode.Root.COM [198.145.90.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA08433
          for <hackers@freebsd.org>; Mon, 22 May 1995 22:50:25 -0700
Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id WAA25119; Mon, 22 May 1995 22:53:27 -0700
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id WAA00561; Mon, 22 May 1995 22:50:29 -0700
Message-Id: <199505230550.WAA00561@corbin.Root.COM>
To: dennis@et.htp.com (dennis)
cc: hackers@FreeBSD.org
Subject: Re: mbuf clusters being lost 
In-reply-to: Your message of "Mon, 22 May 95 23:36:33 EDT."
             <199505230336.XAA16565@mail.htp.com> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Mon, 22 May 1995 22:50:28 -0700
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

>We've been having a problem losing mbufs with a driver that works ok with
>2.0R and other BSD op/sys but not with current. It seems that clusters
>aren't been freed properly, although there are no mbufs that are not being
>freed with m_freem().

   Some specific evidence would be nice...I haven't noticed this problem in
any of the supplied drivers.

>Something has changed since 2.0R...

   *Lots* of things have changed since 2.0R. :-)

>I've noticed that
>netstat -m now accounts for clusters

   I fixed the printf's in netstat to be accurate.

> and that if_ed.c now fails if clusters
>are not available.

   I found that the performance was measurably better and that the driver could
be simplified if I just used clusters in it...so that's what it does now.
Running short on clusters in the previous version would have lead to the
allocation of hundreds of tiny mbufs, linked together in long chains, reducing
performance substantially and wasting memory.

> What has changed.....and why doesn't the original code
>work any more?

   It would help if you described what you are doing and why you think you're
losing mbuf clusters. It's conceivable that -current places a somewhat higher
demand on clusters and that you're just running close to your compiled in
limit. If this is the case, you can increase the limit with options
"NMBCLUSTERS=512" or more if needed. I have future plans of making this
somewhat dynamic, but not before the 2.1 release.

-DG