From owner-freebsd-hackers Thu Jun 29 15:22:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from monk.via.net (monk.via.net [209.81.2.10]) by hub.freebsd.org (Postfix) with ESMTP id 57F8F37C155 for ; Thu, 29 Jun 2000 15:22:34 -0700 (PDT) (envelope-from joe@via.net) Received: (from joe@localhost) by monk.via.net (8.9.3/8.9.3) id PAA10225 for freebsd-hackers@FreeBSD.ORG; Thu, 29 Jun 2000 15:22:53 -0700 (PDT) (envelope-from joe) From: Joe McGuckin Message-Id: <200006292222.PAA10225@monk.via.net> Date: Thu, 29 Jun 2000 15:22:53 -0700 (PDT) To: freebsd-hackers@FreeBSD.ORG Subject: Re[2]: mbuf re-write(s), v 0.1 In-Reply-To: X-Mailer: Ishmail 1.3.1-970608-bsdi MIME-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What about a slab allocator (e.g. http://www.cnds.jhu.edu/~jesus/418/SlabAllocator.pdf) Joe Bosko Milekic wrote: > > On Thu, 29 Jun 2000, David Greenman wrote: > > > We used to do this in FreeBSD, but found that it was a bad idea for > > performance reasons. Freeing and reallocating memory from the high-level > > VM system is quite expensive and the trend in NICs these days is towards > > needing the code to be even faster, not slower. Further, if the 'peak' is > > reached often, then you're probably not really gaining much by freeing > > the memory back to the common pool. > > > > -DG > > What was previously done at some point was use the kernel malloc() to > allocate mbufs. As you know, this is a general purpose allocator that has > to first determine what algorithm to use and then store the object > correctly according to its size. This allocator is faster than that > one. This allocator knows that it only has to deal with mbufs and knows > that all of these mbufs are of the same size. > I am not proposing to return to malloc(), I am proposing the new > allocator. > Also, the "peak" in this case is not reached often, obviously. It is > designed with just that idea in mind. But, if the administrator feels > that it is, I have provided the following mechanism: > > { jehovah:/home/bmilekic }>> sysctl -A | grep min_on_avail > kern.ipc.min_on_avail: 0 > > With this sysctl, the administrator can set a "minimum required" count > for mbufs. In other words, it is possible to easily tell the system to > keep as many mbufs as you'd like cached on the free lists. > > > David Greenman > > Co-founder, The FreeBSD Project - http://www.freebsd.org > > Manufacturer of high-performance Internet servers - http://www.terasolutions.com > > Pave the road of life with opportunities. > > -Bosko > > -- > Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 > bmilekic@technokratis.com * http://www.technokratis.com/ > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Joe McGuckin ViaNet Communications 994 San Antonio Road Palo Alto, CA 94303 Phone: 650-969-2203 Cell: 650-207-0372 Fax: 650-969-2124 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message