From owner-freebsd-hackers Wed Jan 2 1:59:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from technokratis.com (modemcable099.144-201-24.mtl.mc.videotron.ca [24.201.144.99]) by hub.freebsd.org (Postfix) with ESMTP id 81A6937B428; Wed, 2 Jan 2002 01:59:42 -0800 (PST) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id g02A04a00519; Wed, 2 Jan 2002 05:00:04 -0500 (EST) (envelope-from bmilekic) Date: Wed, 2 Jan 2002 05:00:04 -0500 From: Bosko Milekic To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, re@FreeBSD.ORG Subject: Re: huge MFREE() macro? Message-ID: <20020102050004.A402@technokratis.com> References: <200201020616.g026GPE56637@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201020616.g026GPE56637@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, Jan 01, 2002 at 10:16:25PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jan 01, 2002 at 10:16:25PM -0800, Matthew Dillon wrote: > I noticed a bunch of routines use MFREE() instead of m_free() (which > just calls MFREE()). MFREE() is a huge macro. > > text data bss dec hex filename > 1986399 252380 145840 2384619 2462eb kernel > > text data bss dec hex filename > 1983343 252380 145840 2381563 2456fb kernel > > We save about 3K. Any problems with this? Maybe also MFC to -stable > to save some bytes? In -CURRENT, MFREE() just wraps a call to m_free(). > (The #if 0's wouldn't be in a commit, I'd actually delete the code) > > Also, if you do a search for XXX, I think there was an MFREE in there > that should have been an m_freem(). Could someone check that? See below. > The patch is against -stable. > > -Matt > Matthew Dillon > [...] > Index: i386/isa/if_lnc.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/isa/Attic/if_lnc.c,v > retrieving revision 1.68.2.4 > diff -u -r1.68.2.4 if_lnc.c > --- i386/isa/if_lnc.c 8 Jan 2001 15:37:59 -0000 1.68.2.4 > +++ i386/isa/if_lnc.c 2 Jan 2002 06:12:24 -0000 > @@ -839,9 +839,13 @@ > sc->mbuf_count++; > start->buff.mbuf = 0; > } else { > +#if 0 > struct mbuf *junk; > MFREE(start->buff.mbuf, junk); > - start->buff.mbuf = 0; > +#endif > + /* XXX shouldn't this be m_freem ?? */ > + m_free(start->buff.mbuf); > + start->buff.mbuf = NULL; I guess it depends on whether start->buff.mbuf is always a single mbuf or if it ever becomes a chain. If it becomes a chain then it should certainly be m_freem(). How about placing a loop there to traverse forward and count the number of mbufs before m_next == NULL? And, if it is above exactly 1, then change that to an m_freem(). Anyone using lnc? > } > } > sc->pending_transmits--; > @@ -1702,8 +1706,12 @@ > m->m_len -= chunk; > m->m_data += chunk; > if (m->m_len <= 0) { > +#if 0 > MFREE(m, head->m_next); > m = head->m_next; > +#endif > + m = m_free(m); > + head->m_next = m; > } > } > } -- Bosko Milekic bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message