From owner-freebsd-current Mon Nov 25 14:12:46 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B84D37B401; Mon, 25 Nov 2002 14:12:45 -0800 (PST) Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFBBC43EAA; Mon, 25 Nov 2002 14:12:44 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0340.cvx40-bradley.dialup.earthlink.net ([216.244.43.85] helo=mindspring.com) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18GRT3-0003n0-00; Mon, 25 Nov 2002 14:12:37 -0800 Message-ID: <3DE2A006.B72CBD93@mindspring.com> Date: Mon, 25 Nov 2002 14:11:18 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bosko Milekic Cc: Andrew Gallatin , Julian Elischer , Robert Watson , Luigi Rizzo , current@freebsd.org Subject: Re: mbuf header bloat ? References: <15840.8629.324788.887872@grasshopper.cs.duke.edu> <15841.17237.826666.653505@grasshopper.cs.duke.edu> <20021125130005.A75177@unixdaemons.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bosko Milekic wrote: > This is not entirely true. You can allocate an mbuf chain without > holding Giant if the caches are well populated - and they should be > in the common/general case. You can in fact modify the allocator to > just not do a kmem_malloc() if called with M_DONTWAIT, but I don't > think you'd want to do this at this point. In fact, one of the first changes I make in a kernel when I go to do a networking product of any kind is to allocate the mbufs in machdep.c out of physical RAM, and then pre-link them onto a free-list, instead of using the standard (comparatively very slow) mbuf allocator. > The gist of the argument boils down to the fact that network buffer > allocations have different requirements than general all-purpose > allocations (by design, the last time I checked), and that is why > an mbuf/cluster allocator exists. Everything allocated at interrupt has pretty much the same requirements. The only real difference in mbuf's is that the allocation failure cases are generally better handled than all other allocation failure cases within the kernel (or people would not have been beating up Jeff about a month ago for the kmem_map space issue). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message